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Summary 


Navy  acquisition  managers  can  be  provided  with  improved 
information  and  better  decision  support  tools  than  are 
currently  available  to  them  through  the  application  of 
recent  advances  in  information  technology.  Of  several 
acquisition  management  areas  that  could  benefit  from  that 
technology,  acquisition  planning  has  the  potential  for  the 
most  immediate  and  important  gains.  This  conclusion  is 
the  result  of  analysis  by  ROH  Incorporated  and  Computer 
Corporation  of  America,  a  team  with  expertise  in  both  Navy 
acquisition  practice  and  relevant  computer  technology. 
The  team  interviewed  managers  in  NAVSEA  and  NAVMAT,  col¬ 
lected  and  studied  an  extensive  library  of  relevant  docu¬ 
ments,  and  employed  a  recognized  system  analysis  methodol¬ 
ogy  in  reaching  this  conclusion. 

This  report  presents  that  analysis  of  acquisition 
management  activity,  supports  and  details  its  key  conclu¬ 
sions,  and  defines  the  scope  of  the  necessary  work  to  fol¬ 
low.  The  key  recommendation  is  that  the  Navy  continue 
with  a  detailed  study  of  acquisition  planning  and  related 
activity,  with  the  goals  of: 

1.  Specifying  requirements,  in  detail,  for  automated  sup¬ 
port; 

2.  Defining  alternative  system  concepts  to  satisfy  these 
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requirements;  and, 

3.  Recommending  one  concept  of  implementation,  on  the 
basis  of  a  systematic  evaluation  of  technical  and 
management  factors. 

The  present  report  also  describes  some  relevant  tech¬ 
nology  which  is  expected  to  provide  the  key  elements  of  a 
system  to  satisfy  acquisition  management  needs.  These 
elements  -  in  the  areas  of  data  management,  decision  sup¬ 
port  and  business  procedure  management  -  can  be  combined 
in  an  integrated  design,  based  on  a  fuller  understanding 
of  requirements.  Presentation  of  these  technical  concepts 
in  this  report  is  intended  to  suggest  the  type  of  system 
that  may  be  feasible  and  appropriate.  We  stress  that  a 
definitive  system  concept  must  await  further  analysis. 

This  report  was  written  jointly  by  ROH,  Inc.,  and 
Computer  Corporation  of  America  (CCA) .  ROH  is  familiar 
with  Navy  acquisition  practice,  and  has  successfully 
designed,  implemented,  and  supported  ship  acquisition  sys¬ 
tems.  CCA  is  performing  the  leading  research  and  develop¬ 
ment  in  several  areas  of  relevant  computer  technology,  and 
specializes  in  applying  this  technology  in  large  scale, 
operational  systems. 

Approach 

Beginning  with  a  very  broad  work  statement,  the  team 
focused  —  with  Navy  concurrence  —  on  management  of  ship 
acquisition.  Within  that  scope,  the  thrust  of  the  effort 
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has  been  to  define  those  functional  areas  for  which  the 
application  of  advanced  information  technology  holds  the 
promise  of  greatest  benefit. 

After  cataloguing  the  functions  comprising  the 
acquisition  process,  the  project  team  identified  and 
interviewed  a  number  of  high  level  individuals  in  the  ship 
acquisition  community.  The  primary  purpose  of  the  inter¬ 
views  was  to  elicit  opinions  on  which  of  these  functions 
were  particularly  important  and  needed  better  information. 

The  interviews  indicated  that  the  area  of  greatest 
immediate  interest  and  potential  benefit  is  acquisition 
planning.  Specifically,  three  major  components  of  the 
activity  are  of  special  interest: 

1.  Impact  analysis,  which  has  to  do  with  assessing  the 
impact  of  a  proposed  strategy,  plan,  or  change 
thereto ; 

2.  Change  Management,  which  deals  with  implementing 
changes;  and 

3.  Project  Histories,  which  involve  creating  an  accurate 
record  of  what  actually  happened  during  the  life  of  an 
acquisition  project.  These  will  facilitate  the  quan¬ 
tification  of  key  planning  factors,  which  in  turn  sup¬ 
port  impact  analysis. 

In  the  context  used  here,  acquisition  plans  include  both 
programmatic  and  technical  documents. 


The  reasons  stated  by  interview  respondents  for 
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emphasis  on  acquisition  planning  were: 

a.  decisions  made  early  in  the  life  of  an  acquisition 
have  the  most  impact  on  its  success; 

b.  the  visibility  which  acquisition  planning  information 
receives  outside  the  acquisition  community; 

c.  a  perceived  need  for  a  systematically  organized  "cor¬ 
porate  memory"  regularly  refreshed  with  recent  history 
which  can  be  a  major  source  of  insight  for  contem¬ 
porary  acquisition  managers  planning  future  acquisi¬ 
tion  activity; 

d.  a  desire  for  a  common  "fact  base"  available  to  Navy 
acquisition  projects,  fostering  for  the  Navy  an  image 
of  greater  consistency; 

e.  a  belief  that  creating  and  changing  acquisition  plans, 
whether  programmatic  or  technical,  are  where  consider¬ 
able  delay  and  extra  cost  are  introduced  into  the 
acquisition  process. 

Analysis  and  Recommendations 

On  the  basis  of  these  remarks,  a  preliminary  analysis 
of  the  acquisition  planning  activity  was  conducted.  A 
systematic  description  of  the  relevant  functions  was 
developed.  Potential  benefits  of  improving  the  activity 
—  specifically  impact  analysis,  change  management,  and 
project  histories  —  were  identified,  including: 

-  improved  decisions  due  to  more  accurate  and  informative 
evaluation  of  alternatives,  and 

-  more  effective  execution  of  plans  through  improved  com- 
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munication  among  acquisition  participants. 

Impact  analysis  projects  the  effect,  perhaps  across 
projects,  of  proposed  technical  and  programmatic  stra¬ 
tegies  or  plans  or  changes  to  them.  Managers  require  more 
accurate  and  timely  information  than  is  currently  avail¬ 
able  in  order  to  select  among  acquisition  alternatives. 
We  therefore  recommend  detailed  analysis  of  the  require¬ 
ments  for  information  technology  support  of  three  types  of 
impact  analysis: 

1.  Statistical  based  —  This  method  uses  project  his¬ 
tories  to  summarize  past  experience  across  all  pro¬ 
jects  or  across  projects  with  specified  characteris¬ 
tics.  Managers  can  make  projections  based  on  cumula¬ 
tive  and  trend  statistics. 

2.  Case  history  based  —  This  method  uses  project  his¬ 
tories  to  retrieve  experiences  on  individual  projects 
with  specified  characteristics.  Managers  can  make 
projections  based  on  their  interpretations  of  related 
case  histories. 

3.  Model  based  —  This  method  uses  models  (of  varying 
complexity)  to  simulate  and  project  acquisition 
results.  These  models  may  be  based  on  information 
extracted  from  project  histories.  Managers  can  use 
the  models  to  make  projections  based  on  various 
assumptions,  constraints,  or  resource  commitments. 

Since  project  histories  are  important  in  all  three  methods 
of  impact  analysis,  further  study  is  required  to  define 
the  precise  nature  and  content  of  these  histories. 
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Change  management  is  the  function  that  records  the 
decisions  and  notifies  appropriate  members  of  the  acquisi¬ 
tion  community.  Accordingly,  we  recommend  a  detailed 
requirements  analysis  to  determine  how  information  tech¬ 
nology  can  support 

-  recording  programmatic  plans  in  a  form  allowing  direct 
transcription  of  approved  changes, 

-  recording  programmatic  and  technical  changes,  and 

-  notifying  interesed  parties. 

Based  on  the  concerns  and  needs  identified  by  inter¬ 
view  respondents,  several  kinds  of  technology  to  aid 
acquisition  management  are  presented: 

-  Business  procedures  and  communication  (office  automa¬ 
tion) 

-  Electronic  mail 

-  Decision  support  systems 

-  Distributed  databases 

-  Graphic  user  interfaces. 

These  can  be  combined  as  needed. 

Request  for  Comment 

Specific  review,  comment  and  concurrence  or  alterna¬ 
tive  direction  is  requested  from  the  Navy  on  this  recom¬ 
mendation.  Such  review  and  direction  will  ensure  that 
subsequent  work  will  produce  the  desired  results. 
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2.  Goals,  Objectives,  and  Approach 


2.1  Goals 

The  goal  of  this  program  is  to  improve  the  Navy 
acquisition  management  process  through  the  application  of 
advanced  information  management  technology.  The  effort 
will  provide  acquisition  managers  with  necessary  informa¬ 
tion  that  is  accurate,  complete,  and  timely,  and  with 
tools  to  provide  help  in  acting  on  that  information  — 
tools  to  generate  and  evaluate  plans,  implement  and  manage 
changes,  and  coordinate  decisions  and  actions  across 
organizations.  This  will  be  provided  by  appropriate  data¬ 
base,  communications,  and  decision  support  technology. 

Our  first  goal  is  the  improvement  of  ship  acquisi¬ 
tion.  Other  areas,  such  as  weapons  systems,  aircraft,  and 
electronic  systems  will  be  examined  on  the  basis  of 
experience  with  ships. 

This  report  presents  the  approach  and  results  of  our 
efforts  to  define  the  scope  of  the  acquisition  management 
problem  to  be  solved.  The  effort  consisted  of  the  follow- 
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ing  steps: 

.  determine  specific  user  groups  within  the  acquisition 
community, 

.  define  the  management  problems  and  concerns  of  those 
groups , 

.  define  the  functions  and  information  relative  to  those 
concerns,  and 

.  select  areas  for  analysis  based  on  technical  and  organ¬ 
izational  feasibility  and  desirability. 

The  result  of  that  final  step  is  presented  in  this  docu¬ 
ment  as  a  recommendation  to  perform  a  detailed  require¬ 
ments  analysis  in  the  area  of  acquisition  planning. 


2.2  Contractor  Relationship 

This  project  is  a  joint  effort  by  two  prime  contrac¬ 
tors,  ROH  Incorporated  and  Computer  Corporation  of  Amer¬ 
ica,  under  contract  to  the  Office  of  Naval  Research.  ROH 
brings  its  extensive  experience  with  the  Navy  to  this  pro¬ 
ject;  CCA  brings  its  experience  in  requirements  analysis 
and  advanced  database  and  communications  technology. 


Automated  Support  for  Acquisition  Management  Page  -9- 

Goals,  Objectives,  and  Approach  Section  2 

2.3  Approach 

The  approach  taken  in  this  effort  includes  the  fol¬ 
lowing  steps: 

1.  Identify  the  organizations  within  the  ship  acquisition 
community  for  which  support  is  desired. 

2.  For  each  of  these  organizations,  conduct  interviews  to 
gain  understanding  of  its 

a.  environment, 

b.  current  functions, 

c.  concerns  and  goals,  and 

d.  desired  functions. 

3.  Identify  existing  functions  and  the  information  used 
or  produced  by  them.  These  functions  will  include 
decision,  decision  support,  review  and  policy  making 
activities.  Describe  these  functions  and  information 
within  an  overall  framework. 

4.  Identify  common  concerns  and  goals  within  this  frame¬ 
work,  noting  cross-organization  impacts. 

5.  Based  on  perceived  benefit  and  technical  and  manage¬ 
ment  feasibility,  recommend  areas  for  further  analysis 
and  subsequent  support. 

Steps  one  and  two  of  the  approach  were  implemented  by 
interviews  and  document  surveys.  Where  possible,  informa- 
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tion  was  first  obtained  from  the  documents  (see  document 
library,  Appendix  B) .  Interviews  were  then  conducted, 
with  responses  to  be  reported  without  attribution  to  any 
respondent.  As  the  interviews  progressed  the  questions 
evolved  based  on  the  analysis  team's  perception  and 

understanding  of  the  problem.  The  emphasis  was  on 
discovery.  Questions  were  open-ended  to  preclude  res¬ 
tricting  respondents  to  a  narrow  channel  of  thought. 

Figures  2.1  and  2.2  list  the  names  and  organizations 
of  the  interview  respondents. 

The  information  gained  from  the  interviews  and  docu¬ 
ment  surveys  was  documented  in  a  Structured  Analysis  and 
Design  Technique  (SADT  )  model  (see  Appendix  D) .  This 
analysis  methodology  was  selected  because  of  its  suitabil¬ 
ity  for  analyzing  and  describing  the  acquisition  manage¬ 
ment  process,  without  regard  for  automation;  the  results 
of  analysis  using  that  methodology  are  useful  in  selecting 
and  justifying  the  functions  and  information  to  be 
automated. 

The  SADT  model  was  used  as  the  framework  for  further 
questions,  surveys  and  analysis.  All  concerns  and  goals 
were  projected  onto  this  framework  (see  figures  in  Section 
3)  ;  in  this  way,  information-based  solutions  proposed 
within  the  framework  can  be  reviewed  to  determine  how  com- 
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PERSONS  FORMALLY  INTERVIEWED 


RADM  Otth 

MAT 

08 

RADM  Eustace 

SEA 

90 

RADM  Catola 

SEA 

04 

RADM  Beecher 

SEA 

93 

RADM  Lisanby 

SEA 

03 

CAPT.  Skolnick 

PMS 

405/PM 

CAPT.  Underwood 

PMS 

400E 

CAPT.  Peebles 

PMS 

39  6 

Mr.  Banko 

PMS 

389 

CAPT.  Huber 

MAT 

08D 

PERSONS  INFORMALLY  INTERVIEWED 


LCDR  L.  Sadauskas 

SEA  90 

CAPT  E.R.  Burden 

SEA  90 

CAPT.  C.  Piersall 

PMS  377 

CDR.  J.  Elliott 

PMS  377 

Mr.  R.  Link 

SEA  90 

CDR.  R.  Teague 

SEA  90 

Mr.  R.  Bassett 

SEA  OOD 

Ms.  A.  Allison 

SEA  OOD 

Dr.  A.  Feiler 

Log  An,  Inc 

Mr.  J.  Kanmerer 

MAT  01G 

CDR  R.  Clark 

MAT  01 

CDR.  L.  Shaffer 

MAT  08  D 

CDR.  S.P.  Carpenter 

SEA  OOB 

CDR  W.  Pfister 

PMS  377 

CAPT.  E.  Mortimer 

PMS  383 

Mr.  R.  Swart 

PM-2 

Mr.  D.  Whitenight 

SEA  9 OR 

Mr.  D.  Wbytowitz 

PMS  399 

CDR.  T.M.  Shortal 

DDGX 

CDR.  T.  Hassler 

PMS  393 

Mr.  W.  Hirndh 

PMS  393 

Mr.  J.  Schrader 

PMS  303 

CDR.  J.  Colangelo 

SEA  05 

Mr.  J.  Keating 

SEA  074 

Mr.  P.  Barksdale 

PMS  383 

Mr.  V.  Bright 

PMS  383 

Mr.  F.  Anoskey 

PMS  400 

Figure  2 . 2 


pletely  they  address  the  concerns  and  goals. 

Appendix  D  presents  the  complete  framework,  which 
consist  of  the  SADT  models.  Each  box  is  labeled  (below 
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and  to  the  right)  with  a  model  name  (in  this  case  an 
organization  or  organization  code) ,  and  an  activity  iden¬ 
tifier  (such  as  A21) .  Section  3  presents  a  discussion  of 
the  issues  identified  during  the  interviews,  and  their 
relationship  to  the  framework;  the  figures  in  section  3 
are  excerpts  from  the  framework,  and  boxes  in  the  figures 
are  labeled  the  same  as  their  corresponding  boxes  in  the 
framework.  Section  4  contains  the  recommendations  for 
further  study  and  solicits  Navy  concurrence  and  comment. 
Section  5  presents  a  discussion  of  some  support  systems 
that  satisfy  various  aspects  of  the  requirements. 
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3.  Interview  Findings  and  Analysis  of  Results 


3.1  General  Findings 

Interview  respondents  often  discussed  the  need  for 
information  and  other  concerns  in  the  context  of  a  func¬ 
tional  area.  These  areas  of  concern  are: 

1.  Acquisition  planning 

2.  Cost  estimating 

3.  GFE/GFI  management 

4.  Project  financial  management 

5.  Preparation/dissemination  of  management  plans 

6.  Project  problem  management 

7.  Contracts  and  personnel  administration 

The  team  encouraged  the  interview  respondents  to 
describe  the  value  of  information  in  decision-making  func¬ 
tions.  Two  significant  observations  emerged: 

1.  Decisions  made  in  the  early  stages  (prior  to  DSARC 
Milestone  I)  can  generally  be  the  most  significant 
ones  made  during  the  lifetime  of  an  acquisition,  in 
terms  of  impact.  Information  needed  for  such  deci¬ 
sions  is  therefore  more  valuable. 

2.  Decision-making  and  review  functions  fall  into  two 
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categories : 

-  fundamental  functions  that  must  be  performed  in  all 
circumstances,  and 

-  risk  avoidance  functions,  which  are  de-emphasized 
in  times  of  mobilization  or  crisis. 

Respondents  placed  higher  value  on  information  associated 
with  decisions  of  the  first  category.  These  two  observa¬ 
tions  help  explain  the  higher  priority  given  to  some  con¬ 
cerns  and  goals  described  in  section  3.2. 

In  discussing  the  potential  for  automated  support  to 
collect,  share,  and  disseminate  information,  interview 
respondents  cited  two  criteria  for  acceptance: 

1.  Any  automation  must  not  be  disruptive  to  the  organiza¬ 
tion  using  it;  and 

2.  Automated  support  must  allow  an  organization  to  keep 
information  private  until  distribution  is  authorized 
by  the  owner. 

These  issues  are  addressed  in  section  3.3.  Generally,  the 
project  team  found  that  information  has  not  been  willingly 
shared  because  embarrassing  or  confusing  situations 
resulted  when  incomplete,  inaccurate,  inconsistent,  or 
untimely  information  was  used.  Correcting  these  deficien¬ 
cies  and  providing  the  privacy  of  data  will  improve  infor¬ 
mation  sharing. 

One  general  finding  has  impact  on  a  support  system's 
required  flexibility.  Discussions  with  interview  respon- 
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dents  regarding  the  relationship  between  information  and 
decision-making  revealed  that  all  saw  their  decision¬ 
making  as  unstructured  and  largely  reactive  to  external 
stimuli.  This  finding  is  probably  related  to  the  fact 
that  most  of  the  formal  interview  respondents  were  project 
managers  or  higher  in  authority.  Selecting  appropriate 
target  areas  to  support  will  therefore  require  support 
system  capabilities  ranging  from  flexible  ones  to  highly 
structured  ones. 

The  following  section  (3.2)  describes  the  interview 
respondents'  acquisition  management  concerns  and  goals. 
These  are  discussed  in  descending  order  of  value,  based 
on : 

.  perceived  need 
.  potential  for  improvement 

.  potential  for  support  by  information  management  or 
decision  support  technology. 

The  descriptions  are  illustrated  with  figures  extracted 
from  the  overall  framework  that  was  used  to  correlate  raw 
interview  results.  This  framework,  describing  specific 
activities  (boxes)  and  their  associated  information  needs 
and  products  (arrows)  is  shown  in  full  in  Appendix  D. 
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3.2  Acquisition  Functions 


3.2.1  Acquisition  Planning 

An  acquisition  involves  creating  program  plans  and 
technical  plans  and  then  executing  those  plans.  Technical 
plans  include  ship  design  products  such  as  drawings, 
specifications  and  bills  of  material.  These  technical 
plans  evolve  ideally  through  a  series  of  states  referred 
to  baselines,  such  as  conceptual  or  functional  baselines. 
Program  plans  include  a  Ship  Acquisition  Plan,  a  Test  and 
Evaluation  Master  Plan,  an  Operational  Requirement,  and 
Ship  Project  Directives. 

Acquisition  planning  has  three  major  functions  as 
shown  in  figure  3.1.  These  are:  (1)  generate  acquisition 
alternatives  and  strategies,  (2)  evaluate  choices,  and  (3) 
implement  selected  alternatives.  As  the  figure  shows,  a 
major  input  to  the  evaluation  function  is  previous  experi¬ 
ence  in  the  form  of  project  histories.  Interview  respon¬ 
dents  identified  their  acquisition  planning  concerns  to  be 
the  evaluation  function  (called  impact  analysis) ,  the 
implementation  function  (called  change  management) ,  and 
the  information  on  past  experience  (systematic  project 
histories) . 

-  Impact  Analysis  is  the  function  that  largely  involves 
answering  "what  if?"  types  of  questions.  It  is  the 
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Figure  3.1  Impact  Analysis  During  Initial  Planning 

element  of  acquisition  planning  that  evaluates  poten¬ 
tial  program  or  technical  choices.  Evaluation  of 
choices  occurs  during  initial  planning  or  during  execu¬ 
tion  of  previously  accepted  plans.  Impact  Analysis  is 
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discussed  in  sections  3. 2. 1.1  through  3. 2. 1.4. 

-  Due  to  a  number  of  factors  that  arise  in  the  course  of 
a  project,  it  may  become  necessary  to  effect  changes  to 
the  various  acquisition  plans.  For  example,  program 
plans  may  undergo  changes  at  significant  project  review 
points.  Change  Management  is  the  systematic,  discip¬ 
lined  management  of  technical  and  program  plan  changes. 
This  function  is  discussed  in  sections  3. 2. 1.5  and 
3. 2. 1.6. 

-  Systematic  Project  Histories  are  a  major  source  of 
insight  for  acquisition  managers  who  are  planning 
future  acquisitions.  These  histories,  periodically 
refreshed,  are  used  in  impact  analysis.  Histories  are 
discussed  in  sections  3. 2. 1.7  and  3. 2. 1.8. 


3. 2. 1.1  Impact  Analysis  During  Initial  Planning 

Planning  a  project  is  driven  largely  by  PMS-external 
guidance  and  direction,  as  shown  in  figure  3.2.  This  gui¬ 
dance  and  direction  includes  acquisition  strategies  as 
well  as  ship  requirements  based  on  threat  and  ship  mis¬ 
sion.  Various  acquisition  alternatives  must  then  be  iden¬ 
tified;  impact  analysis  evaluates  the  effects  of  selecting 
each  alternative.  As  shown  in  figure  3.3,  the  external 
guidance  and  direction  determines  the  Acquisition  stra¬ 
tegy,  as  well  as  other  philosophies  and  strategies,  e.g., 
T&E,  QA,  ILS,  and  Configuration  Management  (box  PMS/A12  in 
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PMS/A14 


Figure  3.2 
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the  figure) .  The  development  of  specific  plans,  tasks, 
and  schedules  follows  (box  PMS/A13 ) .  Costs  are  estimated 
and  the  total  budget  is  compared  to  budget  ceiling  (box 
PMS/A14) .  Because  the  resulting  costs  and  schedules  may 
be  unacceptable,  alternative  approaches  with  different 
plans,  schedules,  philosophies,  or  strategies  may  be 
developed  and  evaluated. 

This  entire  process,  done  within  each  project  during 
the  initial  planning  phase,  is  inadequate  for  the  Navy's 
needs  as  currently  performed.  Neither  adequate  statistics 
nor  good  modeling  tools  exist  to  reveal  the  impact  of 
various  alternatives  on  costs  and  schedules.  No  sys¬ 
tematic  means  currently  exist  for  bringing  the  Navy's 
cumulative  experience  to  bear  on  this  process,  and  the 
reliability  of  cost  and  schedule  projections  is  limited  to 
the  breadth  of  experience  of  those  creating  and  reviewing 
the  projection. 

The  project  planning  phase  also  includes  contribu¬ 
tions  from  MATO 8  and  SEA90 .  Figure  3.4  shows  this 
interaction.  The  proposed  plans  and  strategies  (produced 
by  box  PMS/A1  in  that  figure)  are  reviewed  by  SEA90  and 
MATO 8 .  Lessons  and  experience  compiled  by  MATO 8 
(MAT08/A24)  and  SEA90  (SEA90/A5)  based  on  results  of  pre¬ 
vious  projects  are  used  to  develop  guidance  and  direction 
on  the  proposed  acquisition  plan  and  may  also  lead  to  some 
alternatives  (top  arrow)  to  be  considered  by  the  PMS. 
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Figure  3.3  Impact  Analysis  During  Ongoing  Project 

The  main  problem  in  this  area  is  the  lack  of  a  sys¬ 
tematic  and  comprehensive  method  for  compiling  experience. 
Status  reports  and  ARB  reports  are  maintained,  but  access 


Page  -22- 
Section  3 


Automated  Support  for  Acquisition  Management 
Interview  Findings  and  Analysis  of  Results 


to  useful  information  is  difficult. 


Guidance  &  Direction  on  Proposed  Plans  &  Alternatives 


Figure  3.4 
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3. 2. 1.2  Impact  Analysis  During  Ongoing  Project 

Figure  3.5  shows  the  functions  and  information  asso¬ 
ciated  with  impact  analysis  as  conducted  within  an  ongoing 
project.  The  ongoing  project  produces  progress  reports 
(from  box  PR0J/A3)  and  technical  documents  (from  box 


Figure  3.5 

PR0J/A4) .  The  technical  documents  include  designs 
(engineering  drawings  and  technical  specifications) ,  test 
results,  and  so  forth.  Progress  reports  (shown  as 
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"progress  against  program  plans"  in  the  figure)  contain 
information  such  as  milestones  achieved,  costs  incurred, 
cost  and  schedule  variances,  problems,  and  projections. 

Inadequately  developed  designs  or  tests,  unacceptable 
test  results  or  unsatisfactory  contract  performance  can 
lead  a  PMS  to  guide  a  contractor  on  technical  matters  or 
to  initiate  program  and  contract  changes,  as  shown  in  fig¬ 
ure  3.6.  Programmatic/contractual  changes  are  of  two 
kinds:  the  first  is  contract  modification  (with  contrac¬ 
tors  or  shipbuilders)  or  redirection  of  tasking  (with 
government  technical  support  organizations) ;  the  second 
requires  replanning,  including  the  impact  analysis 
described  in  the  previous  section  (3. 1.1.1). 

The  difficulties  here  are  identical  to  those  associ¬ 
ated  with  impact  analysis  during  initial  planning:  Pro¬ 
ject  managers,  SEA90,  and  MAT08  have  no  systematic  means 
for  bringing  the  Navy's  collective  experience  to  the  pro¬ 
ject  replanning  process. 


3. 2. 1.3  Impact  Analysis  Across  Projects 

The  Navy  currently  assesses  the  impact  of  one 
project's  technical  and  programmatic  alternatives  on  other 
projects  with  difficulty  because  the  project  relationships 
are  not  formally  understood  and  documented.  Such  was  the 
case  with  the  LHA  and  DD963  projects  at  Ingalls.  Figure 
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3.7  shows  some  of  the  functions  and  information  involved 
in  this  complex  task.  MAT08,  SEA90 ,  and  PARMs,  partici¬ 
pate  in  the  Impact  Analysis  process,  which  evaluates  an 
acquisition  project  alternative  for  its  effect  on  other 
projects  based  on  contention  for  resources  such  as  ship¬ 
builders  and  contractors. 
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Figure  3.7 

Interviews  with  MAT08  and  SEA90  personnel  revealed  a 
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development  of  guidance  based  on  all  projects  extant  or 
foreseen.  The  exact  nature  of  the  desired  tools  was  not 
discovered,  however.  One  project  manager  suggested  that  a 
Navy-wide  catalog  of  contractor  activities  would  help  pro¬ 
ject  planners  recognize  contractor  activity  patterns 
across  projects.  He  believed  that  this  catalog  would 
prevent  abuses  and  assist  in  multi-project  impact 
analysis. 

Government  furnished  equipment  (GFE)  provided  by 
PARMs  to  several  projects  concurrently  is  another  aspect 
of  impact  analysis.  Proposed  changes  in  design  or 
delivery  of  ship  systems  can  impact  several  projects,  as 
shown  in  figure  3.8.  At  present,  this  impact  is  inade¬ 
quately  analyzed  because,  again,  no  systematic  method 
exists  to  determine  the  impact  of  proposed  changes  on  the 
design,  cost,  or  schedule  of  all  related  projects.  (This 
issue  has  a  parallel  in  the  discussion  of  change  manage¬ 
ment.  ) 


3. 2. 1.4  Impact  Analysis  Needs 

We  suggest  three  possible  types  of  Impact  Analysis  to 
improve  this  functional  area  of  acquisition  planning: 
a.  Statistical  based:  This  kind  of  impact  analysis  would 
be  based  on  project  histories  and  makes  projections 
based  on  past  performance  across  all  projects  or  pro- 
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Figure  3.8 

jects  with  some  specific  properties, 
b.  Model  based:  This  kind  of  impact  analysis  would 
require  development  of  a  number  of  models  relating  the 
variables  in  question.  Some  of  these  models  are  quite 
simple,  such  as  the  model  relating  incremental  cost  to 
schedule  change,  manpower  loading  rate  and  cost,  and 
inflation.  Others  are  somewhat  more  complex  but 
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well-defined,  such  as  critical  path  models  — like 
PROMAP  and  TRANSIM —  that  can  be  used  to  determine 
program  schedule  changes  associated  with  task  schedule 
changes.  Finally,  there  are  highly  complex  analyses 
for  which  reliable  and  accurate  models  have  yet  to  be 
completely  formulated.  The  cost  estimating  model 
currently  being  developed  by  TASC  for  the  Acquisition 
Review  Council  is  in  this  category, 
c.  Case  history:  This  kind  of  impact  analysis  would 
require  project  histories  that  contain  information 
about  key  project  characteristics  and  experiences. 
This  information,  which  need  not  have  pre-defined  for¬ 
mat  or  classification,  could  help  answer  "what  if  ..." 
questions  with  "what  happened  when  ..."  answers.  This 
kind  of  impact  analysis  requires  further  definition  of 
the  type  of  information  needed. 

Key  issues  to  be  answered  include: 

-  The  nature  of  project  histories,  and  definition  of 
their  contents 

-  Access  rights  to  project  histories 

-  Access  rights  to  specific  analysis  tools 

-  The  nature  of  required  "Lessons  Learned",  defini¬ 
tion  of  contents,  information  source,  access 
rights. 

A  thorough  requirements  analysis  in  these  areas  should  be 


conducted. 
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3. 2. 1.5  Change  Management 

Change  management  involves  selecting  from  among 
alternative  plans  and  effecting  the  change  by  communicat¬ 
ing  it  to  interested  or  affected  parties.  Change  manage¬ 
ment  includes  both  technical  and  programmatic  changes. 
Figure  3.9  shows  highlights  of  the  change  management  func¬ 
tion.  Based  on  an  impact  analysis,  a  proposed  engineering 
or  programmatic  change  may  require  modifying  or  negotiat¬ 
ing  a  contract  with  a  shipbuilder  or  contractor,  or  modi¬ 
fying  or  negotiating  an  agreement  with  a  PARM  or  other 
government  activity  for  technical  support.  Based  on  the 
proposal  or  estimate  (input  to  box  PMS/A2) ,  programmatic 
or  engineering  changes  are  negotiated  (lower  output  of 
PMS/A2) .  The  task  plans  and  budgets  must  be  modified 
(upper  output  of  box  PMS/A2 )  to  insure  accurate  progress 
reporting  (PROJ/A3  to  PMS/A3)  and  the  engineering  change 
(if  any)  must  be  recorded  (output  of  box  PMS/A3) . 

From  an  information  management  viewpoint,  change 
management  includes  four  information  recording  or  communi¬ 
cating  activities: 

a.  Record  the  engineering  change,  if  any; 

b.  Communicate  the  engineering  changes  to  appropriate 
PARMs,  shipbuilders,  etc.; 

c.  Record  the  program  plan  changes; 

d.  Communicate  the  program  plan  changes  to  appropriate 
PARMs,  shipbuilders,  etc. 

Engineering  changes  are  currently  recorded  after  ECP's 
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have  been  approved,  but  the  manner  in  which  this  is  done 
varies  from  project  to  project.  Further,  access  to  this 
change  information  is  difficult.  It  is  not  clear  how  well 
these  records  are  organized  and  maintained,  but  interview 
respondents  noted  that  poor  maintenance  of  these  records 
leads  to  difficulty  in  claims  management,  a  known  problem. 
Recording  program  plan  changes  also  appears  to  be  an  area 
of  difficulty.  No  systematic  means  for  updating  the  plans 
was  discovered  during  the  interviews.  By  implication, 
financial  management  becomes  less  reliable. 

The  final  area  of  difficulty  in  change  management, 
and  perhaps  the  most  significant,  is  communication  of 
changes  among  impacted  parties.  One  situation  discussed 
during  the  interviews  concerned  GFE  provided  by  a  PARM:  If 
a  PARM  must  make  an  engineering  change  to  some  ship  sys¬ 
tem,  the  impacted  PM,  shipbuilder,  and  related  contractors 
(and  perhaps  other  PARMs)  must  be  notified  of  the  change. 
This  was  illustrated  earlier  in  figure  3.8.  Interview 
respondents  noted  that  communication  of  engineering  or 
program  change  among  the  impacted  parties  is  currently 
inadequate. 
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3. 2. 1.6  Change  Management  Needs 

We  suggest  that  further  detailed  analysis  be  con¬ 
ducted  in  the  following  areas  of  recommended  improvement: 

1.  The  original  program  plan  should  be  recorded  in  a  form 
that  will  allow  direct  transcription  of  approved 
changes. 

2.  The  program  plan  should  be  revised  directly  from  any 
formal  impact  analysis,  if  performed,  or  should  be 
revised  as  needed  for  situations  not  worthy  of  a  for¬ 
mal  impact  analysis.  This  procedure  will  preclude 
delays  and  transcription  errors. 

3.  The  engineering  changes  should  be  recorded.  They  can¬ 
not  be  used,  however,  to  revise  the  technical  plans 
until  technical  plans  are  recorded  in  a  form  allowing 
direct  transcription  of  technical  drawings  and  specif¬ 
ications  . 

4.  Program  plans,  as  modified,  and  engineering  changes 
should  be  transmitted  to  interested  parties,  and  such 
communication  should  cause  revision  of  the  recipient's 
records  (as  in  (1)  and  (3)). 

We  also  suggest  that  a  detailed  analysis  be  conducted  to 
determine  how  the  change  management  process  updates  the 
project  histories. 
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3. 2. 1.7  Systematic  Project  Histories 

Systematic  Project  Histories  involve  establishing  and 
maintaining  a  "corporate  memory"  —  a  source  of  informa¬ 
tion  containing  acquisition  project  experience.  This  data 
can  be  used  to  facilitate  both  Impact  Analysis  and  Change 
Management.  The  high  ranking  that  interview  respondents 
gave  to  improvement  in  this  area  indicates  their  awareness 
of  its  vital  nature.  However,  there  was  not  universal 
agreement  as  to  the  desirable  contents  or  use  of  such  his¬ 
tories;  neither  was  there  agreement  on  responsibility  for 
maintaining  them. 

At  present.  Project  Histories  are  not  systematically 
maintained:  Lessons  learned  are  lost  and  different  pro¬ 
jects  work  from  different  fact  bases,  making  the  Navy 
appear  inconsistent  and  unreliable. 


3. 2. 1.8  Systematic  Project  History  Needs 

The  key  to  defining  project  histories  is  understand¬ 
ing  their  use:  Project  histories  cannot  be  studied 
independently,  but  must  be  studied  in  the  context  of 
impact  analysis  and  change  management.  We  suggest  further 
requirements  analysis,  therefore,  to  define  the  nature, 
content,  and  use  of  project  histories,  particularly  in  the 
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following  areas: 

1.  How  are  histories  used  to  aid  inter-project  and 
intra-project  impact  analysis?  What  specific  informa¬ 
tion  needs  of  impact  analysis  can  be  satisfied  by  pro¬ 
ject  histories? 

2.  How  are  histories  refreshed  to  include  progress  and 
experiences? 

3.  How  are  these  histories  used  by  MATO 8 ,  SEA90 ,  and  PMs? 
Are  the  components  of  histories  private  to  projects? 


3.2.2  Cost  Estimating 

Developing  cost  estimates  is  a  difficult  and  time 
consuming  procedure.  Inaccurate  cost  estimating  has  led 
to  management  difficulty  and  lack  of  Navy  credibility, 
particularly  during  Congressional  hearings.  It  is  not 
surprising,  then,  that  cost  estimating  support  was  ranked 
high  in  desirability  by  interview  respondents. 

To  develop  a  reasonable  cost  estimate,  several  dif¬ 
ferent  cost  estimating  methods  —  including  bottom  up  and 
top  down  —  are  used  by  different  organizations;  these 
estimates  generally  do  not  agree,  but  should  be  close. 
Estimates  made  by  the  same  method,  but  based  on  different 
underlying  assumptions,  may  also  disagree.  Thus,  it  can 
be  misleading  or  confusing  to  present  a  cost  estimate 
without  its  underlying  assumptions  or  its  calculation 


method. 
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There  are  two  aspects  of  cost  estimating  that  must  be 
considered.  One  is  the  cost  estimating  process  itself; 
this  is  a  computational  and  modeling  problem  that  is  the 
subject  of  another  Acquisition  Research  Council  effort. 
The  other  is  the  recording  of  the  cost  estimate  together 
with  its  basis  for  calculation;  this  is  an  information 
management  issue. 

A  major  weakness  in  current  practice  seems  to  be  a 
lack  of  systematically  maintained,  easily  accessed  record 
of  individual  cost  estimates  with  their  attendant  basis 
for  calculation,  as  shown  in  figure  3.10.  Interview 
respondents  ranked  improvement  in  this  area  highly. 
Further  study  may  show  that  cost  estimate  recording  can  be 
included  as  part  of  the  methodology  developed  for  main¬ 
taining  Systematic  Project  Histories. 


3. 2. 2.1  Cost  Estimating  Needs 

If  cost  estimating  memory  is  to  be  supported,  several 
issues  related  to  cost  estimates  and  the  basis  for  calcu¬ 
lation  must  be  resolved  in  the  next  phase  of  this  project: 

a.  Identify  the  basis  of  calculation  of  cost  estimates. 
At  least  the  following  must  be  considered: 

-  What  input  data  was  used? 

-  What  assumptions  are  made  (e.g.,  acquisition  alter- 
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Figure  3.10 

natives,  labor  situations,  inflation  rate)? 

-  Which  algorithm  or  technique  was  used  to  compute 
the  estimate? 

-  What  experience  is  reflected  in  this  estimate, 
i.e.,  what  components  of  project  histories  influ¬ 
enced  the  estimate? 

-  What  previous  estimates  were  considered  or  were  the 
starting  point  for  this  estimate? 
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b.  Define  the  access  rights  to  these  estimates  and 

assumptions:  Are  estimates  and  assumptions  for  pro¬ 

ject  use  only  (as  shown  in  figure  3.11)  or  are  they  to 
be  included  in  collective  Navy  experience  (see  figure 
3.12)  for  use  on  all  projects?  The  latter  is  desir¬ 
able  but  poses  privacy  problems. 

c.  Determine  whether  and  when  the  estimates  and  assump¬ 
tions  become  a  component  of  private  or  public  project 
histories.  Are  working  estimates  recorded  in  private 
histories? 

d.  Define  the  storage  life  of  the  estimates  and  assump¬ 
tions  and  determine  whether  these  should  be  stored  in 
full.  If  older  estimates  with  assumptions  are  stored 
in  synopsized  form,  determine  when  summarizing  occurs. 

e.  Define  the  relationship  that  exists  between  the  most 
recent  estimates  and  project  plans  and  financial 
management  (to  be  discussed  in  section  3.2.4). 
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Figure  3.12 
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3.2.3  GFE/GFI  Management 

GFE/GFI  Management  involves  maintaining  an  accurate 
record  of  GFE/GFI  status  and  acting  to  assure  timely  and 
complete  delivery  of  undamaged  GFE  and  accurate  GFI. 
Acquisition  managers  interviewed  mentioned  two  general 
problem  areas,  GFE/GFI  change  management  and  GFE/GFI 
status  reporting. 

GFE/GFI  change  management  includes  identifying 
changes  in  GFE/GFI  (figure  3.13),  identifying  the  impacts 
on  associated  projects,  and  implementing  any  changes  (fig¬ 
ure  3.14).  This  kind  of  impact  analysis  and  change 
management  is  covered  in  section  3.2.1. 

There  are  two  facets  to  the  GFE/GFI  status  reporting 
and  recording  problem.  From  an  information  management 
viewpoint,  the  problem  is  one  of  determining  the  nature  of 
the  information  that  is  transmitted  among  the  PARMs,  PMs, 
shipbuilders,  and  contractors.  From  a  communications 
viewpoint,  the  information  transmitted  is  unimportant:  The 
issue  is  one  of  notification. 

Further  study  is  required  to  determine  the  signifi¬ 
cance  of  each  of  these  aspects.  This  area  was  ranked  by 
interview  respondents  somewhat  lower  than  the  previously 
discussed  areas,  however. 
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3. 2. 4.1  Financial  Management  Functions 

Two  of  the  essential  elements  of  classical  management 
are  maintaining  accurate  budgets,  journals  and  ledgers, 
and  preparing  appropriate  financial  reports.  In  current 
practice,  each  acquisition  project  tends  to  develop,  at 
considerable  cost,  its  own  unique  system  of  financial 
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management.  These  systems  have  many  elements  of  financial 
management  in  common. 

Figure  3.15  illustrates  the  major  functions  and 
internal  information  associated  with  project  financial 
management.  Internal  project  budgets  are  developed 
(PMS/A14  in  the  figure)  based  on  plans  and  schedules  pre¬ 
viously  developed  (by  PMS/A13) .  These  internal  budgets, 
the  basis  for  the  Congressional  Budget  submissions,  are 
used  with  the  plans  to  negotiate  and  approve  any  contracts 
(PMS/A2) .  The  contract  is  issued,  and  performance  on  the 
contract  is  reported  by  the  shipbuilder  or  contractor 
( PR0J/A3 )  Based  on  these  reports,  particularly  cost  and 
schedule  variance,  the  PMS  may  determine  a  need  to 
redirect  a  contractor,  modify  a  contract,  and/or  revise 
the  plans  and  budgets.  Interaction  with  PARMs  is  similar 
to  the  interaction  with  shipbuilders  or  contractors. 

The  information  mentioned  in  the  financial  management 
process  falls  into  three  categories.  One  category  is 
working  information  of  long  term  interest,  including: 

1.  plans,  tasks,  and  schedules, 

2.  internal  budgets  and  obligation  plans,  and 

3.  terms  of  approved  contracts. 

The  most  recent  versions  of  these  are  maintained  in  acces¬ 
sible  form  while  old  versions  are  part  of  history. 

The  second  category  is  information  of  immediate 
interest  when  published,  and  of  historical  value  after 
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that,  including: 

1.  contractor,  shipbuilder,  and  PARM  status  reports,  and 

2.  internal  project  status,  which  may  be  used  to  develop 
external  status  reports  (e.g.,  NSATS,  SAR) . 

The  third  category  of  information  is  of  a  transitory 
nature  although  of  high  interest,  including: 

1.  need  to  revise  plans,  schedules,  and  budgets,  and  mag¬ 
nitude  of  needed  change,  and 

2.  need  to  modify  contracts  with  shipbuilders/contractors 
or  agreements  with  PARMs,  and  magnitude  of  needed 
change. 

These  are  generally  mental  notes  and  are  of  a  transitory 
nature. 

External  status  reporting,  illustrated  in  figure 
3.16,  makes  use  of  information  in  the  first  two  categories 
mentioned  above.  Project  status  reports  are  developed 
(PMS/A3  in  the  figure)  based  on  budgets,  plans,  schedules, 
and  progress  reports  from  contractors,  shipbuilders,  and 
PARMs.  These  are  reviewed  by  MAT08  (MAT08/A23)  and  SEA90 
(SEA90/A4).  Project  status  reports  currently  are  produced 
in  several  forms,  including  NSATS  and  SAR. 

In  discussing  the  needs  associated  with  the  recording 
and  reporting  of  financial  data,  interview  respondents 
identified  two  needs  but  valued  them  differently.  High 
value  was  placed  on  improvement  in  change  management  of 
plans  and  budgets  associated  with  financial  management. 
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Improvement  in  recording  and  reporting  of  actual  costs  and 
progress  was  not  valued  highly ,  although  respondents  noted 
that  developing  NSATS  and  SAR  reports  from  these  actual 
data  was  a  time  consuming  effort. 


3. 2. 4. 2  Financial  Management  Needs 

Requirements  analysis  should  proceed  in  several  areas 
if  this  function  is  selected  for  further  study. 

In  the  area  of  general  ledgers,  journals,  and  budg¬ 
ets,  at  least  three  issues  must  be  addressed: 

1.  What  relationship  exists  between  the  budget  and  any 
plans?  How  does  the  change  management  function,  with 
influence  over  plans,  also  revise  the  budget  and 
schedules,  if  at  all? 

2.  Do  budgets,  journals,  and  ledgers  have  predefinable 
characteristics  that  may  change  from  project  to  pro¬ 
ject? 

3.  How  are  the  budgets  structured  and  related  to  general 
ledgers  and  journals  so  that  progress  reports  can  be 
reliably  and  accurately  produced? 

With  regard  to  reporting,  two  areas  of  need  should  be 
studied: 

1.  If  budgets  and  schedules  are  not  revised  by  change 
management  functions,  how  are  status  reports  produced 
showing  progress  against  the  most  recent  plans  and 
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budgets? 

2.  How  are  NSATS ,  SAR,  and  other  project  progress  reports 
developed?  Can  some  sections  be  calculated  automati¬ 
cally  while  other  sections  remain  manually  created? 

Further  study  is  also  needed  to  determine  whether 
progress  reports  are  to  be  stored  as  part  of  project  his¬ 
tories,  and  if  so,  what  use  is  made  of  them.  Specifi¬ 
cally,  the  relationship  between  storage  and  production  of 
progress  reports  and  development  of  "lesson  learned"  must 
be  determined.  Figure  3.17  illustrates  the  transforma¬ 
tion.  (This  area  overlaps  study  required  to  understand 
the  need  for  project  histories.) 


3.2.5  Preparing  and  Disseminating  Various  Management 
Plans 


The  interview  respondents  expressed  a  concern  about 
the  amount  of  labor  expended  to  prepare,  revise,  review, 
and  distribute  the  programmatic  documents  involved  in  ship 
acquisition.  This  was  mentioned  as  an  area  contributing 
to  excessive  costs  and  delays  in  the  acquisition  process. 

Although  interview  respondents  did  not  give  high 
priority  to  support  for  this  function,  the  use  of  more 
contemporary  information  management  and  word  processing 
methods  would  significantly  enhance  this  function.  If  the 
Navy  desires  further  effort  in  this  area,  we  recommend 
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analysis  to  determine  the  relationship  between  this  func¬ 
tion  and  change  management.  Specifically,  several  ques¬ 
tions  should  be  addressed: 

1.  Which  plans  maintained  and  refreshed  by  change  manage¬ 
ment  are  presented  in  formal  documents? 

2.  Which  plans  are  maintained  as  text,  and  which  are 
tabular,  graphic,  or  otherwise  machine  interpretable? 

3.  What  relationship  exists  between  tabular  or  graphic 
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format  plans,  which  may  be  regularly  maintained,  and 
textual  documents  published  periodically  incorporating 
the  latest  tabular  or  graphic  plans? 

4.  What  document  version  control  support  is  required  to 
keep  track  of  documents  and  the  state  of  the  plans 
that  comprise  them? 


3.2.6  Project  Problem  Management 

There  is  general  recognition  that  the  typical 
acquisition  manager  and  his  staff  spend  a  substantial  por¬ 
tion  of  their  time  managing  problems.  These  can  be  techn¬ 
ical  or  programmatic,  but  almost  always  involve: 

1.  defining  the  problem 

2.  correlating  the  problem  with  other  problems 

3.  analyzing  the  problem 

4.  generating  a  corrective  action 

5.  implementing  the  corrective  action 

6.  verifying  that  the  problem  is  solved. 

At  any  given  time,  an  acquisition  project  may  have  hun¬ 
dreds  of  problems  in  various  of  the  above  stages,  with  a 
number  of  outside  organizations  involved. 

Clearly,  a  systematic  discipline  for  problem  manage¬ 
ment  is  indispensable.  Yet  project  managers  who  were 
interviewed  did  not  apparently  have  a  common  discipline  or 
support  system,  nor  did  they  give  high  priority  to 
developing  support  for  this  area.  Detailed  requirements 
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Figure  3.18 

analysis  in  this  area  would  determine  which  of  the  above 
six  steps  required  support,  if  the  Navy  believes  this  area 
deserves  further  study. 


3.2.7  Contracts  Administration  and  Personnel  Administra¬ 
tion 


There  was  general  agreement  that  Contract  Administra¬ 
tion  (such  as  performed  by  NAVSEA  002)  and  Personnel 
Administration  (such  as  performed  by  NAVSEA  02)  are  func¬ 
tions  that  contribute  greatly  to  delays  and  increased 
costs  in  the  acquisition  process  because  of  their  inabil¬ 
ity  to  respond  in  timely  fashion.  But  there  was  no  con- 
sensus  on  how  to  solve  these  problems,  nor  was  there  any 
indication  that  solving  them  was  possible  within  the  scope 
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of  this  project.  No  further  study  in  this  area  is  recom' 
mended  for  this  project. 


Figure  3.19 
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3.3  Design  and  Implementation  Considerations 

As  indicated  in  section  3.1,  several  interview 
respondents  raised  concerns  about  how  information  manage¬ 
ment  tools  should  be  implemented  within  the  functional 
areas  discussed  in  section  3.2. 

One  concern  commonly  identified  by  interview  respon¬ 
dents  was  that  any  acquisition  support  tools  must  insure 
the  privacy  and  security  of  the  user's  acquisition  data. 
Respondents  were  concerned  that  unrestricted  access  to 
confidential,  private,  or  working  information  by  those 
unfamiliar  with  its  content  or  meaning  could  lead  to 
embarrassment  or  confusion  —  loss  of  effectiveness  in 
managing  one's  project,  in  short.  Privacy  and  security  is 
therefore  a  critical  requirement  in  the  design  of  any 
information  tools  that  can  facilitate  information  sharing. 
We  recommend  that  any  further  analysis  determine  the 
privacy/security  needs  for  all  information  associated  with 
functions  selected  for  detailed  requirements  analysis. 

Another  attitude  commonly  encountered  was  the  reluc¬ 
tance  of  well-established  acquisition  project  organiza¬ 
tions  to  accept  changes  to  the  way  information  is 
currently  handled  because  changes  are  seen  as  disruptive 
to  existing  practices.  Newly  established  acquisition  pro¬ 
ject  organizations,  on  the  other  hand,  seem  to  be  more 
receptive  to  improved  information  management.  This  atti¬ 
tude  difference  must  be  considered  when  choosing 
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organizations  at  which  to  implement  information  tools 
developed  by  this  project. 
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4.  Recommendations 

The  objective  of  this  phase  of  the  project  is  to 
define  the  scope  of  the  Acquisition  Support  Tools  require¬ 
ments  analysis.  The  major  product  of  this  phase,  then,  is 
definition  of  specific  targets  for  automated  support. 

Collectively,  the  interview  respondents  identified 
the  major  concerns  detailed  in  section  3,  specified  the 
value  of  supporting  the  areas  of  concern,  and  described 
their  receptivity  to  automated  solutions  for  those  prob¬ 
lems.  One  finding  was  that  well-established  acquisition 
projects  are  reluctant  to  change  current  methods  of  infor¬ 
mation  management.  One  implication  of  this  finding  is 
that  tools  implemented  to  directly  support  established 
project  management  would  not  necessarily  be  widely 
accepted. 

There  was  widespread  agreement  regarding  another 
finding.  Decisions  made  in  the  early  stages  of  an 
acquisition  (prior  to  DSARC  Milestone  I)  are  generally  the 
most  significant  ones  -  by  virtue  of  their  impact  made 
during  the  lifetime  of  an  acquisition.  The  value  of  sup¬ 
port  in  acquisition  planning  was  therefore  rated  as  high, 
and  such  support  could  most  likely  be  welcomed  as  non- 
disruptive.  Support  for  other  functions  not  presently 
well  supported  (manually  or  automatically)  would  also  be 
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seen  as  beneficial. 

The  major  recommendation  of  this  effort,  therefore, 
is  that  development  pi  automated  suppoxt  should  focus  pa 
the  acquisition  planning  function,  including  impact 
analysis.  change  management  and  systematic  project  his¬ 
tories.  The  relevant  information  of  interest  must  be 
defined  and  its  usefulness  documented.  The  requirements 
analysis  should  continue  to  develop  detail  within  the 
framework  already  documented  here. 

The  CCA/ROH  project  team  looks  forward  to  Navy  con¬ 
currence  and  comment  on  this  recommendation. 
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5.  Some  Designs  to  Satisfy  Acquisition  Needs 


5.1  Introduction 

Previous  sections  of  this  scoping  document  deal  with 
acquisition  management  issues,  with  little  regard  for 
preconceived  system  designs  that  could  influence  discovery 
of  acquisition  management  needs.  Having  documented  a  gen¬ 
eral  understanding  of  the  requirements  however,  a  look  at 
the  available  technology  can  be  useful:  understanding  the 
potential  for  automated  support  can  open  the  discussion  to 
acquisition  problems  that  might  have  been  thought  unsolv- 
able. 


For  that  reason,  this  section  presents  some  examples 
of  the  application  of  advanced  technology  to  acquisition 
management.  Each  system  addresses  some  aspect  of  the 
requirements  discussed  in  section  3.  All  employ  technol¬ 
ogy  that  has  already  been  developed  and  demonstrated;  some 
employ  technology  that  has  already  been  commercially  pack¬ 
aged. 


It  is  important  to  note  that  components  of  each  of 
these  systems  can  be  recombined  to  create  a  system  satis¬ 
fying  all  the  needs  identified  by  the  Navy.  These  systems 
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are  presented  to  show  how  advanced  automation  technology 
can  be  applied  to  solve  specific  requirements  and  should 
not  be  considered  strawman  proposals. 


5.2  A  Database  Facility  for  Acquisition  Management 

Improvements  in  such  functions  as  acquisition  plan¬ 
ning,  impact  analysis  and  change  management  rest  ulti¬ 
mately  on  better  management  of  information.  Most  of  the 
information  desired  in  these  functions  usually  exist  some¬ 
where  in  the  community  -  or  in  some  readily  tapped  exter¬ 
nal  source.  The  central  problem  is  to  make  the  needed 
information  available  to  the  right  decision  makers,  at  the 
right  times,  and  in  forms  that  are  useful  for  their  pur¬ 
poses.  A  key  aspect  of  this  problem  is  the  management  of 
the  computer  resident  databases  themselves. 

Computerized  databases  are  expensive  and  valuable 
resources  which  must  be  managed  with  as  much  care  as 
inventories  of  valuable  materials,  stockpiles  of  expo- 
sives,  or  installations  of  expensive  equipment.  The  key 
problems  to  be  addressed  in  database  management  are: 

1.  data  availability  for  both  standard  reports  and 
unusual  or  unanticipated  questions; 

2.  access  control,  so  that  each  piece  of  information  is 
available  only  to  those  authorized  to  use  it; 

3.  data  validation  to  insure  that  data  is  correct  -  at 
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entry  when  possible  -  and  always  before  use; 

4.  data  independence  so  that  changes  to  details  of  one 
aspect  of  operations  do  not  disrupt  others  (e.g.r 
changes  to  database  format  should  not  affect  users  or 
running  application  software) ; 

5.  data  consistency,  so  that  the  various  elements  of  the 
database  provide  a  logically  consistent  description  of 
the  objects,  activities  and  organization  they  concern; 

6.  data  integration,  so  that  information  from  multiple 
sources  can  be  combined  effectively  to  provide  a  com¬ 
plete  picture  of  factors  which  may  relate  to  a  deci¬ 
sion. 

Database  management  systems  -  functionally  complete 
systems  of  software  that  provide  integrated  solutions 
addressing  all  of  these  needs  -  have  been  commercially 
available  since  about  1970.  One  part  of  a  program  to 
improve  the  information  available  to  the  acquisition  com¬ 
munity  will  be  to  employ  recent  database  management  tech¬ 
nology. 

There  are  three  types  of  information  which  must  be 
managed  within  the  acquisition  community;  local  operating 
data,  selected  shared  management  data  and  community  infor¬ 
mation. 

Local  Operating  Data 

Local  operating  data  is  data  collected  by  individual 
organizational  units  for  use  within  those  units,.  For 
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example,  acquisition  projects  may  collect  data  on  the 
status  of  work  in  progress  under  their  contracts.  Good 
operating  data  at  the  unit  level  is  the  foundation  of 
effective  information  management  at  all  other  levels. 
Good  policy  and  effective  strategic  planning  is  possible 
only  when  basic  operating  data  is  sound. 

However,  there  are  two  prime  requirements  for  the 
development  of  good  databases  within  operating  units,  such 
as  the  acquisition  project: 

1.  The  data  must  be  gathered,  stored  and  disseminated 
locally  in  forms  -  and  according  to  standards  -  that 
are  genuinely  responsive  to  local  needs;  and, 

2.  The  organization  responsible  for  maintaining  the  data 
must  control  access  to  it  and  dissemination  of  it. 

Only  if  these  principles  are  followed  will  project 
managers  feel  that  the  data  exists  primarily  to  benefit 
their  operation.  Unless  they  feel  that  the  data  is  for 
them,  it  will  never  be  very  accurate  or  timely.  The  mili¬ 
tary  has  many  automated  systems  that  have  failed  because 
they  do  not  serve  —  or  honor  the  management  prerogatives 
of  —  unit  commanders.  These  systems  almost  always  fail 
primarily  because  the  data  stored  in  them  is  unreliable. 

These  principles  are  important  in  any  organization, 
but  they  are  especially  important  in  the  acquisition  com¬ 
munity.  In  this  community: 

a.  Projects  are  highly  autonomous,  and  project  managers 
are  strongly  committed  to  preservation  of  their 


Automated  Support  for  Acquisition  Management  Page  -63- 

Some  Designs  to  Satisfy  Acquisition  Needs  Section  5 

management  prerogatives;  and, 
b.  There  are  significant  variations  in  the  detailed 
information  needs  of  the  various  projects,  due  to 
differences  in  project  age,  acquisition  philosophy, 
system  to  be  delivered,  technology  and  other  factors; 
imposition  of  uniform  database  designs  on  all  projects 
in  the  case  of  operating  data  -  would  be  a  grave 
mistake. 

Consequently,  local  operating  data  must  be  managed  in 
databases  flexibly  structured  to  respond  to  the  needs  of 
the  operating  unit.  These  databases  must  be  controlled  by 
the  operating  unit  and  local  access  restrictions  must  be 
respected  by  the  entire  community. 

Selectively  Shared  Data 

The  second  important  category  of  data,  selectively 
shared  data,  flows  between  operating  units  for  purposes  of 
management  reporting,  coordination,  joint  planning,  or 
cooperative  action.  Examples  of  this  data  are  project 
status  reports,  financial  reports,  change  notices,  and 
schedules.  In  many  cases  the  content  of  reports  sent  from 
one  organization  to  another  is  drawn  from  local  operating 
data.  Some  routine  reports  can  be  prepared  automatically 
from  local  data.  Others  can  be  developed  only  from 
management  interpretation  and  aggregation  of  local  data. 

The  important  requirement  concerning  selectively 
shared  data  is  that  access  to  it  is  still  carefully  con- 
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trolled.  Thus  some  data  may  be  available  only  to  special 
task  groups  or  inter-project  working  groups.  Some  data 
may  be  internal  to  NAVSEA  -  other  data  may  flow  between 
project  managers  to  the  Acquisition  Review  Board,  but  not 
be  generally  available.  The  point  here  is  not  to 
encourage  secrecy,  but  to  respect  the  ordinary  practices 
of  management.  Information  can  generally  be  used  most 
productively  in  an  organization  when  it  is  complete,  con¬ 
sistent,  validated  and  evaluated.  Systems  that  inadver¬ 
tently  lead  to  the  dissemination  of  unevaluated  data  are 
often  counter-productive. 

Community  Information 

Community  information  is  data  gathered  for  the  bene¬ 
fit  of  the  entire  community.  It  is  stored  in  a  database 
available  to  the  entire  acquisition  community.  Examples 
of  community  information  are: 

-  macroeconomic  planning  factors 

-  industrial  capacity  data 

-  industrial  product  lead  times 

-  labor  union  actions  (e.g.,  strikes,  potential 
strikes,  and  slowdowns) 

-  public  information  on  shipbuilding  or  Navy  policy 

-  regulations 

-  information  reported  to  Congress 

-  Congressional  directives. 

Certain  information  originating  as  local  operating  data 
may  eventually  become  community  information.  For  example, 
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certain  aspects  of  project  histories  may  be  valuable  to 
all  planners  -  and  may  be  freely  available  to  the  entire 
community.  (Other  such  data  may  be  more  closely  held  — 
the  system  must  accommodate  all  choices) . 

Figure  5.1  presents  a  conceptual  view  of  the  needed 
information  structure.  The  outermost  ring  represents 
operating  databases  created  by  each  group  for  use  within 
that  group.  The  diagram  shows  that  there  is  no  sharing  of 
data  among  groups  in  the  other  ring.  Thus  only  SEA90  may 
access  the  SEA90  database. 

The  inner  circle  represents  a  community  database 
available  to  all  groups. 

The  middle  ring,  representing  selectively  shared  data 
is  made  up  of  many  databases,  each  available  to  certain 
groups.  Thus,  one  database  contains  information  that 
SEA90  and  MATO 8  share  to  coordinate  their  joint  activi¬ 
ties.  Another  contains  data  of  joint  interest  to  MATO 8 , 
PMSl  and  PMS2 .  A  third  contains  data  to  be  accessed  by 
SEA90 ,  PMS2,  and  PARM1 .  Note  that  this  selectively  shared 
data  is  distinct  from  the  local  operating  data  in  the 
outer  ring.  No  doubt  PMSl  would  move  data  from  its  local 
database  to  the  shared  databases  only  after  it  was  vali¬ 
dated,  consistent  and  ready  for  release. 

Important  characteristics  of  this  architecture  are: 
a.  data  sharing  is  controlled,  protecting  autonomy  of 
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SEA90,  MAT08,  PMS1,  PMS2,  PARM1,  SUPSHIP1,  SUPSHIP2  -  are  names  of  organizational 
units;  each  unit  may  access  databases  labelled  with  it?  name. 


Figure  5.1  Conceptual  Database  Architecture 
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local  operations;  but 

b.  arbitrarily  complex  patterns  of  cooperation  and  data 
sharing  are  supported. 

This  appears  to  suit  the  needs  of  the  acquisition  commun¬ 
ity  exactly. 


5.2.1  Distributed  Database  Technology 

Recent  developments  in  database  technology  make  the 
operation  of  distributed  databases  practical.  A  database 
is  said  to  be  distributed  when: 

a.  it  is  broken  up  into  pieces; 

b.  the  pieces  are  dispersed  to  multiple,  autonomously 
operating  computers  which  may  be  geographically  dis¬ 
tributed;  and, 

c.  the  distribution  is  hidden  from  users  and  application 
programs. 

Distributed  database  technology  is  of  special 
interest  in  the  acquisition  community  because  of  its  geo¬ 
graphically  dispersed  operations  and  requirements  for  both 
data  sharing  and  project  autonomy.  One  approach  to  apply¬ 
ing  the  technology  would  involve  the  use  of:  (a)  large 
shared  computers  for  community  data,  and  (b)  minicomputers 
for  local  operating  data.  Then  individual  units  would 
exercise  exclusive  operational  control  over  computers 
housing  their  operating  data.  For  widely  shared  data, 
economies  of  scale  and  the  simplicity  of  centralized 


Page  -68-  Automated  Support  for  Acquisition  Management 
Section  5  Some  Designs  to  Satisfy  Acquisition  Needs 

operation  would  apply.  Selectively  shared  data  can  be 
distributed  over  the  minicomputers  or  stored  centrally. 
The  choice  can  be  made  on  a  case  by  case  basis. 


5.2.2  Application  in  the  Acquisition  Community 

The  distributed  database  described  here  has  the 
potential  to  become  the  principal  repository  for  all 
management  information  in  the  acquisition  community.  Both 
information  of  local  interest  to  a  single  unit  or  project, 
and  information  to  be  shared  among  or  exchanged  by  multi¬ 
ple  units,  becomes  part  of  the  database.  Thus  the  data¬ 
base  will  contain  project  histories,  estimated  and  actual 
costs,  plans,  schedules,  and  status  information.  The 
database  will  be  the  repository  for  such  information  as 
alternative  plans  under  consideration  and  impact  analyses, 
as  well  as  such  specific  information  as  change  notices. 

It  is  vitally  important  to  understand  that  all  such 
data  will  typically  enter  the  network  as  part  of  a  local 
database  —  as  working  data.  In  this  status,  it  is  stored 
on  the  local  computer  and  is  not  available  via  the  network 
to  other  groups.  Thus,  if  a  project  has  discovered  that  a 
key  contractor  is  behind  schedule  —  and  several  alterna¬ 
tive  programmatic  changes  are  under  consideration  —  the 
information  concerning  contractor  status  and  alternative 
responses  would  typically  be  entered  initially  in  the 
project's  local  database.  At  some  point  the  project 
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management  will  be  prepared  to  begin  discussing  alterna¬ 
tive  courses  of  action  with  shipyard  supervisors,  PARMs, 
upper  management,  etc.  At  that  point,  when  it  is 
appropriate  to  make  status  information  and  plans  more 
widely  available,  the  project  manager  can  release  relevant 
data  to  the  network  database.  It  is  of  central  importance 
that : 

a.  all  management  data  can  be  entered  into  the  network  of 
databases  from  its  moment  of  origin;  but, 

b.  control  over  the  release  and  dissemination  of  the  data 
is  at  all  times  in  the  hands  of  the  owner  of  the  data. 

Thus  creation  of  the  data  —  or  entry  of  it  into  the  data¬ 
base  —  is  wholly  separate  from  dissemination  or  sharing 
of  it. 


Data  in  the  database  is  accessed  by  data  query  sys¬ 
tems,  decision  support  systems,  business  procedure  manage¬ 
ment  systems  and  other  tools  described  in  later  sections 
of  this  report.  All  such  systems  employ  the  database  sys¬ 
tem  to  handle  their  data.  Thus  all  systems  are  subject  to 
the  same  data  access  control  and  exhibit  the  same  indepen¬ 
dence  of  data  location.  All  systems  can  be  used  in  local 
operations  on  local  data,  and  in  joint  operations  on 
shared  data.  And  all  systems  use  the  same,  internally 
consistent  collection  of  databases. 
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5.3  Decision  Support  for  Acquisition  Planning 


5.3.1  System  Description 

This  system  will  provide  computer  support  for  initial 
planning  of  acquisition  projectsf  and  for  planning  of 
major  changes.  Its  philosophy  is  to  support  decision¬ 
making  by  demonstrating  the  effects  of  various  alterna¬ 
tives.  The  system  is  not  intended  to  derive  automatically 
an  optimal  allocation  of  resources. 

This  system  will  allow  the  acquisition  community  to 
create  and  exercise  a  model  that  simulates  the  acquisition 
environment.  All  system  displays  will  be  graphic. 

A  model  creation  facility  will  allow  users  to  formu¬ 
late  a  graphically  represented  macro  model  of  organiza¬ 
tions  that  participate  in  the  acquisition  process.  Tasks 
can  be  defined  for  each  participating  organization,  and 
for  each  task, 

a)  prerequisite  products  produced  by  other  tasks, 

b)  required  resources, 

c)  task  products,  and 

d)  schedules 

are  defined.  Resources  are  user-defined  but  normally 
include  man-hours,  facilities  (such  as  dry  docks)  and 
Products  can  also  be  user-defined.  The  relation- 


money. 
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ship  between  a  task's  prerequisite  products,  the  resources 
consumed  and  the  products  produced  can  be  defined  by  a  set 
of  parameters  that  are  also  user-defined.  These  parameters 
(planning  factors)  should  in  fact  be  based  on  historical 
statistics  gathered  from  previous  acquisition  projects 
(systematic  project  histories). 

The  activities  that  can  be  represented  in  this  model 
are  those  that  actually  contribute  to  the  production  of 
ships.  These  include  PMSs,  PARMs,  shipbuilders,  and  con¬ 
tractors.  The  system  will  allow  a  user  to  define  an 
organization  that  creates  products  used  by  two  others, 
consuming  limited  resources.  This  is  shown  in  figure  5.2. 
This  implicitly  defines  interrelationships  such  as  those 
existing  between  two  acquisition  projects. 

The  system  will  support  impact  analysis  through  a  top 
down  analysis  of  resource  and  schedule  requirements.  The 
basic  logic  needed  is  similar  to  that  used  in  Material 
Requirement  Planning  (MRP)  systems.  In  MRP  systems,  a 
desired  output  schedule  is  specified;  a  "bill  of  materi¬ 
als"  explosion  together  with  the  lead  times  for  procuring 
prerequisite  products  and  resources  are  used  to  determine 
the  required  schedule  of  available  input.  Here  the  "bill 
of  materials"  is  a  list  of  prerequisite  products  and 
resources,  including  labor  and  money.  The  system  then 
uses  the  capacities  of  the  participant  organizations, 
defined  in  terms  of  facilities  and  resources  available,  to 
generate  constraints  on  the  inputs  available  for  use. 
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These  constraints  are  compared  with  the  schedule  of  input 
availability  required  to  produce  the  desired  output.  If 
any  constraints  are  violated,  alternative  output  schedules 
that  satisfy  the  constraints  can  be  generated.  These 
alternatives  demonstrate  the  impact  that  project  changes 
have  on  the  cost  and  schedule  of  all  possible  affected 
projects. 

A  critical  aspect  is  that  the  system  is  not  intended 
to  derive  an  optimal  production  schedule.  To  do  so  would 
involve  subjective  tradeoffs  between  cost  and  value  of 
different  projects.  Rather,  the  system  will  support 
decision-making  by  showing  the  effects  of  selecting  vari¬ 
ous  alternatives,  and  by  demonstrating  the  costs  (in  terms 
of  basic  resources)  of  these  choices. 

A  well-designed,  user-oriented  interface  will  make 
the  system  a  working  tool  for  planning.  The  interface 
must  provide: 

1.  graphic  display  capability 

2.  storage  of  system  inputs  and  assumptions  (models) 

3.  storage  of  system  outputs  (results) 

4.  capability  for  easily  changing  model  characteristics 

5.  appropriate  summary  capability 

6.  terminology  and  formats  familiar  to  the  user 

These  factors  must  all  be  usable  with  a  minimum  amount  of 


training. 


Page  -74-  Automated  Support  for  Acquisition  Management 
Section  5  Some  Designs  to  Satisfy  Acquisition  Needs 

5.3.2  System  Use 

Specifying  available  resources  does  not  uniquely 
determine  production  schedules  and  costs  of  Navy  ships. 
Assignment  of  these  resources  to  specific  tasks  is 
required.  Therefore,  the  Acquisition  Planning  Decision 
Support  System  will  be  used  to  derive  the  various  feasible 
alternative  production  schedules  and  the  resources 
required  to  implement  them,  based  on  different  allocations 
of  resources  (such  as  shipyard  capacity) .  Identifying 
these  alternatives  will  show  where  potential  bottlenecks 
and  trouble  spots  exist,  and  help  identify  trade-offs  that 
can  be  made  to  improve  overall  results. 

This  system  can  be  used  by  SEA90  or  MAT08  to  analyze 
interproject  impacts.  Such  analysis  will  allow  the  Navy 
to  optimize  its  programs  Navywide  without  suboptimizing 
for  a  particular  project.  This  would  be  done  as  follows:  A 
model  can  describe  the  interrelationships  among  a  number 
of  existing  projects,  shipbuilders,  PARMs  and  contractors, 
as  shown  earlier  in  figure  5.2.  The  interrelationship 
between  projects  through  common  shipbuilders  would  be  evi¬ 
dent,  and  the  effect  of  one  project  on  a  particular  ship¬ 
builder  can  be  translated  into  the  effect  on  another  pro¬ 
ject.  These  kinds  of  effects  can  be  explored  by  exercising 
the  model.  The  results  of  such  simulations  can  be 
displayed  graphically  in  real  time  using  color  where 
necessary.  The  product  of  each  simulation  can  be  stored 
along  with  the  assumptions  (such  as  specific  acquisition 
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strategies)  that  were  made.  Thus,  a  number  of  choices  in 
acquisition  strategies  can  be  simulated  so  that  acquisi¬ 
tion  planners  with  PMSs,  MATO 8 ,  and  SEA90  can  select  the 
approach  most  beneficial  to  the  Navy. 

Project  managers  can  also  use  the  system  to  determine 
the  optimal  strategy  within  a  particular  project,  subject 
to  the  constraints  applied  by  higher  authority.  The  sys¬ 
tem  would  be  used  to  evaluate  alternative  strategies  for 
constructing  a  ship  class  given  a  number  of  shipyards  with 
limited  capacity.  This  is  shown  in  figure  5.3.  The  ship¬ 
yard  capability  would  be  calculated  from  the  total  pro¬ 
jected  capability  less  all  current  or  planned  commitments 
to  other  projects.  This  system  can  also  be  used  to  deter¬ 
mine  the  effect  of  a  change  in  a  PARM's  plans  on  the  costs 
and  schedules  of  all  projects  supported  by  that  PARM. 


5.4  Communications  and  Filing 

In  several  of  the  areas  discussed  in  Section  3,  the 
issue  of  communications  among  participants  in  the  acquisi 
tion  process  is  mentioned.  Communications  improvements 
beyond  telephone  and  mail  — —  can  be  achieved  with  the  sup¬ 
port  of  several  different  kinds  of  systems  (automated  or 
electronic) : 

a.  Message  forwarding  systems,  on  which  messages  can  be 
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Learning  Curve) 
at  its  Estimated 
Cost. 


Figure  5.3 
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sent  to  active  parties  on  a  network 

b.  Electronic  tele-conferencing  with  audio  and  video 

c.  Electronic  mail. 

Message  forwarding  systems  are  easy  to  use  and  can  be 
simply  designed.  They  often  require  sending  and  receiving 
parties  to  be  on-line;  variations  store  messages  until  the 
receiving  party  comes  on-line.  No  electronic  filing,  com¬ 
posing,  and  retrieving  capability  generally  exists  within 
this  class  of  systems,  and  these  functions  are  performed 
manually  before  or  after  transmission. 

Electronic  teleconferencing  offers  the  obvious  advan¬ 
tage  of  visual  contact  without  the  need  to  travel.  This 
tool  would  be  effective  for  decision-making  or  fact  find¬ 
ing  conferences  where  parties  can  coordinate  their 
schedules. 

Electronic  mail  is  an  effective  working  tool  if  the 
parties  must  receive  and  send  at  their  convenience.  Such 
systems  also  support  filing  and  retrieving  of  messages,  so 
that  communications  are  virtually  self  documenting.  They 
also  interface  directly  to  databases  for  access  to 
required  information. 

The  system  described  below  is  a  variation  of  elec¬ 
tronic  mail.  Some  examples  of  how  it  can  be  used  in  the 
acquisition  environment  follow. 
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The  Navy  already  employs  electronic  message  technol¬ 
ogy  to  support  its  worldwide  operations.  The  current  dis¬ 
cussion  is  concerned  with  more  pervasive  use  of  this  tech¬ 
nology  -  employing  somewhat  different  system  designs  -  for 
maximum  benefit  to  ship  acquisition  management. 


5.4.1  System  Description 

A  centralized  system,  with  dial-up  access  by  means  of 
local  terminals,  will  provide  message  composing,  transmit¬ 
ting,  and  filing  facilities. 

The  message  composing  facility  allows  users  to  create 
and  edit  messages  consisting  of  three  kinds  of  components; 

.  Header  blocks  contain  sender,  receiver,  and  title  of 
message.  There  can  be  only  one  of  these  per  message. 

.  Text  blocks  contain  any  text.  There  can  be  as  many 
text  components  as  needed  per  message. 

.  Tabular  blocks  contain  tables  of  data.  There  can  be  as 
many  tabular  components  as  needed  per  message. 

Standard  text  and  tabular  block  form  definitions  can 
be  created  and  stored.  Use  of  these  can  standardize  mes¬ 
sage  formats  and  facilitate  the  composition  process. 

Block  contents  can  be  filled  in  from  the  terminal, 
can  be  extracted  from  blocks  in  other  messages,  or  can  be 
created  from  a  database.  Text  blocks  'can  be  modified 
using  text  editing/word  processing  functions.  Arithmetic 
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manipulation  of  tabular  block  contents  is  also  possible. 

Automated  distribution  of  messages  can  supply  an 
easy,  quick  means  of  sending  messages  to  the  intended 
recipients  at  their  respective  terminal  sites.  Messages 
can  be  addressed  to  individuals  or  to  user  defined  distri¬ 
bution  lists.  Messages  are  forwarded  on  command  and  are 
available  when  their  recipients  are  active  on  the  system. 

Messages  are  stored  in  user  defined  files  for  subse¬ 
quent  retrieval.  Unsent  messages  can  be  kept  in  the  files 
for  documentation  purposes  or  can  be  called  up  for  subse¬ 
quent  revision.  Received  messages  can  be  retrieved  from 
the  files  for  review.  Users  can  also  search  files  for 
messages  that  contain  specific  words  or  phrases. 

A  touch-sensitive  graphic  interface  would  allow  fil¬ 
ing  and  retrieval  of  messages  by  picking  a  file  from  a 
picture  showing  all  user  defined  files.  New  file  names 
would  be  entered  from  the  keyboard.  Touch  sensitive 
graphics  would  also  allow  creation  of  header  blocks  from 
displays  of  previously  defined  distribution  lists  or  indi¬ 
viduals. 

To  prevent  the  disclosure  of  sensitive  data  and  the 
unauthorized  access  to  the  forms  and  their  contents,  the 
system  will  provide  internal  security  mechanisms  which 
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include: 

1.  access  rights  verification  by  "credit  card"  device 

2.  cryptographic  controls  such  as  data  encryption  accord¬ 
ing  to  the  1977  National  Bureau  of  Standards  encryp¬ 
tion  algorithm;  and 

3.  passwords  for  data  files 

Since  data  and  forms  manipulation  and  storage  will  occur 
locally/  transmission  of  information  to  other  organiza¬ 
tions  will  take  place  only  with  the  explicit  intention  and 
consent  of  the  local  user.  Forms  information  can  be 
released  either  by  connection  of  the  local  system  to  a 
central  computer  for  public  use  or  by  mail  using  cassettes 
and  floppy  disks  to  selected  individuals.  Existing  pro¬ 
cedures  for  handling  and  transporting  classified  documents 
can  be  employed  when  cassettes  or  floppy  disks  contain 
classified  information. 


5.4.2  System  Use  in  Acquisition  Context 

This  system  will  serve  to  satisfy  the  communication 
and  documentation  needs  of  the  acquisition  community  in 
the  following  ways: 

.  Change  Management  -  Proposed  and  approved  changes  can 
be  communicated  to  affected  parties  using  messages  com¬ 
posed  primarily  of  text,  and  some  programmatic  plan 
changes  can  be  shown  in  tabular  form.  The  messages  can 
be  sent  to  parties  on  standard  distribution  lists: 
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PARMs  can  notify  all  appropriate  PMSs  of  changes;  PMSs 
can  notify  PARMs  and  contractors  of  changes.  By  filing 
the  messages,  PARMs  and  PMSs  can  maintain  a  history  of 
changes. 

.  Financial  Management  —  Financial  plans  can  be  docu¬ 
mented  using  tabular  blocks  in  messages.  Plans  can  be 
reported  when  necessary,  and  only  at  the  appropriate 
level  of  summarization  (using  tabular  summarizing  func¬ 
tions)  .  New  plans  can  be  documented  by  copying  tabular 
data  from  old  plans.  For  financial  status  reporting, 
PMSs,  contractors,  and  report  reviewers  can  use  this 
facility.  Financial  status  reports  can  show  tabular 
data  extracted  from  plans  and  contractor  reports,  with 
variances  automatically  calculated  by  tabular  manipula¬ 
tion  functions.  Explanatory  text  can  be  extracted  from 
various  contractor  reports,  with  additional  material 
entered  by  the  PMS.  Reports  can  be  distributed  at  the 
will  of  the  PMS,  and  PMS  and  all  recipients  can  file 
the  report  in  their  private  project  histories  for  their 
own  use. 

.  Cost  Estimating  -  Cost  estimates  can  be  prepared  using 
tabular  form  capabilities,  with  text  blocks  documenting 
the  assumptions  made.  Cost  estimates  can  then  be  filed 
in  the  local  project  history  file  and  retrieved  based 
on  date,  assumption,  and  so  forth.  No  distribution 
would  occur,  except  possibly  for  desired  external 


review. 
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5.5  Business  Procedure  System 

Two  needs  mentioned  by  interview  respondents  were 
improved  communication  among  acquisition  participants  and 
reduction  in  paperwork  (both  production  and  review) .  Much 
of  the  paperwork  can  be  standardized,  such  as  NSATS  and 
SAR  reporting.  Some  of  these  procedures  —  again  SAR  and 
NSATS  are  examples  —  require  interoffice  standardization 
and  include  interoffice  communication.  Other  procedures, 
such  as  problem  management  within  a  PMS,  can  be  standard¬ 
ized  within  one  office,  requiring  only  intra-office  com¬ 
munication. 

One  way  to  support  standard  procedures  and  communica¬ 
tions  is  with  a  business  procedures  system  (office  automa¬ 
tion)  ,  some  of  which  are  commercially  available.  They 
allow  definition  of  automated  standard  forms  as  well  as 
automated  standard  procedures  for  completing,  routing,  and 
filing  these  forms.  These  automated  procedures  are 
tailored  to  the  working  procedures  already  in  use.  Office 
automation  systems  also  provide  electronic  mail  and  filing 
capabilities  for  non-standard  office  action. 

Since  office  automation  systems  are  flexible,  changes 
in  standard  procedure  —  due  to  changed  acquisition  regu¬ 
lations  or  management  —  can  be  accommodated.  Improve¬ 
ments  in  management  methods  and  needs  fpr  additional  pro¬ 
cedures  can  also  be  satisfied  without  completely  replacing 
the  system. 
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The  description  of  such  a  system  and  examples  of  its 
use  follow. 


5.5.1  System  Description 

The  system  is  composed  of  a  dispersed  series  of  con¬ 
veniently  located  workstations,  with  graphic  screens. 
Each  can  have  local  processing  capability  or  can  operate 
through  a  central  processor  of  suitable  size  (see  figure 
5.4)  . 


The  business  procedures  office  automation  system  sup¬ 
ports  an  organization's  standard  procedures  and  forms. 
The  system  automatically  routes  and  files  electronically 
maintained  and  displayed  forms  to  the  workstations,  each 
of  which  supports  tasks  performed  by  that  organization's 
personnel . 

The  system  is  tailored  to  a  specific  office  as  fol¬ 
lows  . 

1.  Each  office  procedure  is  broken  down  into  the  sequence 
of  its  composite  steps.  Each  of  these  steps  may  con¬ 
tain  varying  amounts  of  data  entry  and  data  review. 
The  sequence  of  steps,  which  can  be  represented  as  a 
flowchart,  may  include  decision  points  that  are 
branches  in  the  path  based  on  the  presence,  absence, 
or  value  of  some  data  (see  top  half  of  figure  5.5). 

2.  The  standard  forms  for  each  procedure  are  defined. 
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Figure  5.4 
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The  data  within  each  form  are  identified  and  defined. 
3.  For  each  step  (transaction) ,  those  sections  of  the 
forms  that  are  filled  in  or  reviewed  are  identified, 


Hckjlq  Srepn 

Additional 

Data 


Figure  5.5 

and  the  operations  performed  on  those  sections  are 
defined.  Possible  operations  include  data  entry, 
verification,  viewing,  copying  (from  other  forms,  pos¬ 
sibly)  ,  editing,  or  manipulating  (possibly  by  a 
mathematical  or  tabular  operation) .  Decision  opera- 
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tions  are  also  identified,  and  the  decision  criteria 
are  specified. 

4.  The  transactions  are  assigned  to  work  stations  (see 
bottom  half  of  page  5.5). 

Thus,  each  workstation  is  used  to  complete  at  least  one 
step  in  some  office  procedure.  Workstations  can,  at  dif¬ 
ferent  instances,  support  different  steps,  possibly  within 
different  procedures. 

Besides  standard  procedures  defined  for  a  particular 
office,  workstations  may  also  have  several  "utility"  func¬ 
tions.  These  allow  users  to  perform  various  office 
related  functions  at  their  own  convenience  for  their  own 
purposes.  They  include: 

-  word  processing 

-  electronic  mail 

-  filing  of  electronic  messages 

-  appointment  calendars  and  travel  plans 

Special  utilities  may  also  be  provided  that  allow  verify¬ 
ing  progress. 

In  operation,  this  business  procedures  system  elec¬ 
tronically  maintains  and  routes  all  paperwork.  Those  who 
wish  to  initiate  some  action  do  so  by  completing  the  first 
step  in  the  appropriate  procedure;  this  may  require  (par¬ 
tial)  completion  of  a  form.  Upon  completion  of  that  step, 
the  form  is  automatically  routed  to  the  next  station. 
When  that  station  comes  on-line,  the  forms  waiting  for 
action  at  that  station  become  available.  Completion  of 
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the  next  step  results  in  routing  to  subsequent  stations. 
Completion  of  a  procedure  (as  defined  by  the  user  of  the 
system)  may  occur  when  final ,  approved  documents  are 
routed  to  one  or  more  parties  for  their  information  or  for 
action  within  their  office.  The  recipient  may  then  ini¬ 
tiate  one  of  his  procedures. 


5.5.2  System  in  Use  in  Acquisition  Environment 

This  system  potentially  can  support  the  "paperwork" 
and  communication  in  such  areas  of  acqusition  management 
as  engineering  change  management,  program  change  manage¬ 
ment,  financial  reporting,  and  financial  plan  preparation 
and  dissemination.  An  example  for  financial  reporting 
follows : 

Financial  Reporting 

A  number  of  workstations  are  located  at  the  PMSs, 
MATO 8 ,  SEA90,  PARMs,  shipbuilders,  and  contractors.  The 
business  procedures  system  is  used  to  accummulate  cost  and 
schedule  reporting  data. 

Contractors,  shipbuilders,  and  PARMs,  accumulate  and 
report  costs  and  milestone  progress  in  the  manner  of 
(CS)  .  Reporting  is  as  shown  in  figure  5.6. 

Contractors  and  shipbuilders  enter  costs  and  mile¬ 
stone  progress  by  means  of  the  automated  system,  using 
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Figure  5.6 

standard  but  flexible  forms.  PARMs  assemble  costs  and 
milestone  progress  reports  by  project,  using  features  that 
extract  sections  of  contractor  reports  and  recompose  them 
for  project  reporting, 

PMSs  receive  contractor,  PARMs,  and  shipbuilder 
reports  in  standard  form  through  the  electronic  mail 
feature.  Several  of  the  the  clerical  aspects  of  preparing 
NSATS  and  SAR  reports  are  performed  at  one  workstation  in 
the  PMS ,  as  shown  in  figure  5.7.  The  result  is  a  working 
draft  that  is  private  to  the  PMS.  This  is  edited  at 
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perhaps  another  workstation  until  the  report  is  suitable 
for  publication.  The  electronic  mail  feature  is  then  used 
to  forward  the  reports  to  MAT08  or  SEA90. 

At  each  step  in  the  reporting  procedure  it  is  possi¬ 
ble  to  insert  the  report  into  local  private  project  his¬ 
tories.  PMSs  can  maintain  all  contracts,  shipbuilding, 
and  PARM  reports  in  a  PMS  local  history  file.  This  would 
be  implemented  as  follows:  The  workstation  transaction 
defined  for  reading  contractor,  shipbuilder,  and  PARM 
reports  would  automatically  insert  these  reports  into  a 
file  called  "history".  The  transaction  would  also  allow 
entry  of  key  points  in  the  report  by  which  subsequent 
retrieval  might  be  desired.  MAT08  and  SEA90  would  also 
have  workstation  transactions  defined  for  receiving  NSATS 
and  SAR  reports.  Initial  reading  would  include  the  fol¬ 
lowing  steps. 
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Figure  5.7 
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Machine 


Acquisition  User 


1.  display  the  report 


read  report 


2.  identify  reported 
unsatisfactory  or 
marginal  areas 


verify 


3.  identify  routing 
within  MAT08  or  9 
for  special  review 
due  to  unsatisfactory 
areas 


verify,  add,  or 
delete 


4.  request  special 


supply  characteristics 


characteristics  for 
later  retrieval 

5.  save  in  MAT08  on 
SEA90  local  project 
histories;  route  to 
appropriate  parties 
within  MAT08  in  SEA90 
for  review 

Additional  checking  could  also  be  incorporated  in  initial 
or  subsequent  readings.  Options  include; 

-  Automatic  retrieval  of  the  previous  reports  showing 
current  and  previous  projections  side  by  side. 

-  Automatic  retrieval  of  previously  defined  plans  to  com¬ 
pose  current  and  plan  project  progress.  (This  assumes 
that  plans  are  reported  to  or  entered  at  MATO 8  or  SEA90 
using  the  system,  and  that  these  plans  are  in  a  form 
suitable  for  direct  comparison  to  NSATS  and  SAR. ) 

-  Automatic  highlighting  of  areas  to  review  based  on 
"flags"  set  by  reviewers  of  previous  reports.  (This 
assumes  that  on  each  review,  reviewers  specify  those 
sections  of  the  standard  form  report  to  review  care¬ 
fully  on  the  subsequent  report.) 
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5.6  Graphical  Data  Management  and  Display 

Spatial  Data  Management  is  a  technique  for  organizing 
and  retrieving  information  by  positioning  it  in  a  Graphi¬ 
cal  Data  Space  (GDS) .  This  Graphical  Data  Space  is  viewed 
through  a  color  raster  scan  display  which  enables  users  to 
traverse  the  GDS  surface  or  zoom  into  the  image  to  obtain 
greater  detail.  In  contrast  to  conventional  database 
management  systems  in  which  users  access  data  by  asking 
questions  in  a  formal  query  language,  a  Spatial  Data 
Management  System  (SDMS)  presents  the  information  graphi¬ 
cally  in  a  form  which  seems  to  encourage  browsing  and  to 
require  less  prior  knowledge  of  the  contents  and  organiza¬ 
tion  of  the  database. 

Because  of  its  flexibility  in  answering  unstructured 
questions,  this  technique  appears  to  be  appropriate  for 
the  acquisition  community. 


5.6.1  System  Description 

Spatial  Data  Management  is  motivated  by  the  needs  of 
a  growing  community  of  people  who  need  to  access  informa¬ 
tion  in  a  database  management  system  (DBMS)  but  who  are 
not  trained  in  the  use  of  such  systems.  The  information 
in  an  SDMS  is  expressed  in  graphical  form  and  presented  in 
a  spatial  framework,  so  that  the  information  is  more 
accessible  and  its  structure  is  more  obvious  than  in  a 
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conventional  DBMS.  In  this  way,  a  user  can  find  the 
information  he  seeks  without  having  to  specify  it  pre¬ 
cisely  or  know  exactly  where  in  the  DBMS  it  is  stored. 

The  graphical  data  space  is  accessed  through  a  set  of 
three  color,  raster-scan  displays.  The  left-most  of  the 
three  screens  presents  a  "world-view"  map  of  the  entire 
data  surface.  A  magnified  portion  of  this  data  surface  is 
simultaneously  displayed  on  the  main  screen  in  the  center. 
The  location  on  the  data  surface  of  this  magnified  portion 
is  indicated  by  a  highlighted  rectangle  which  appears  on 
the  world-view  map.  The  user  can  control  which  portion  of 
the  data  surface  appears  on  the  main  display  by  pressing 
on  the  joy  stick  shown  in  the  foreground  of  the  figure  in 
the  user's  left  hand.  Pressing  the  joy  stick  in  any  given 
direction  causes  the  user's  magnified  window  to  move  in 
that  direction  over  the  data  surface.  This  motion  is 
reflected  in  the  corresponding  motion  of  the  highlighted 
rectangle  on  the  world-view  map. 

The  data  presented  to  the  user  on  the  main  display 
can  come  from  a  variety  of  sources  including  any  symbolic 
database  management  system. 

A  Spatial  Data  Management  System  offers  several 
advantages  over  conventional,  keyboard-oriented  database 
management  systems,  including  those  offering  natural 
language  or  "English-like"  user  interfaces.  Six  such 
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advantages  are: 

1.  Motion  through  database  is  simple  and  natural. 

2.  The  database  is  its  own  data  dictionary. 

3.  The  presentation  of  the  data  encourages  browsing. 

4.  The  placement  of  the  data  can  convey  information. 

5.  Graphics  can  be  used  to  convey  information. 

6.  The  system  can  accommodate  many  unique  data  types  such 
as  photographs. 

These  are  discussed  below. 


5. 6. 1.1  Motion  Controls 

The  joy  stick  of  SDMS  provides  a  simple  and  natural 
means  of  moving  through  the  database.  By  using  one  con¬ 
trol,  the  joy  stick,  the  user  can  explore  the  entire  data¬ 
base.  On  the  other  hand,  symbolic  query  languages  require 
the  use  of  a  special  syntax  and  semantics.  Even  in 
natural  language  systems,  where  the  syntax  is  widely  known 
and  the  semantics  relatively  intuitive,  the  user  must 
learn  the  structure  and  contents  of  the  database  before  he 
can  find  anything.  In  contrast,  the  data  in  an  SDMS  can 
be  displayed  in  a  manner  which  makes  the  contents  and 
structure  readily  apparent,  and  does  not  require  any  prior 
knowledge  of  the  structure  of  the  database  in  order  to 
retrieve  information  from  it. 

The  level  of  abstraction  at  which  the  data  is  exam¬ 
ined  is  similarly  easy  to  control.  Twisting  a  knob  zooms 
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the  picture  and  thus  specifies  the  level  of  detail  which 
is  displayed,  allowing  the  user  to  see  global  attributes 
such  as  the  number  of  objects  in  a  set  without  the  burden 
of  utilizing  separate  functions  for  aggregation.  In  addi¬ 
tion,  if  the  database  administrator  has  set  up  more  ela¬ 
borate  abstractions,  these  can  be  invoked  by  the  user  by 
the  same  simple  mechanism,  requiring  no  additional 
knowledge  on  his  part. 

When  dealing  with  very  large  databases  this  control 
of  detail  makes  it  possible  for  the  user  to  see  the  entire 
database  on  the  world-view  display,  even  if  there  are  more 
elements  in  the  database  than  can  occupy  discrete  posi¬ 
tions  on  the  television  screen.  The  database  administra¬ 
tor  need  merely  define  an  abstraction  which  groups  the 
data  elements  together  in  some  suitable  manner.  For  exam¬ 
ple,  a  database  of  ships  might  be  grouped  according  to 
hull  type.  The  more  abstract  views  of  the  graphical  data 
space  would  then  display  the  groups  instead  of  the  indivi¬ 
dual  elements,  allowing  the  user  to  see  the  entire  data¬ 
base  and  move  quickly  to  the  location  of  some  particular 
area  of  interest.  Once  he  had  centered  that  area  on  the 
screen,  twisting  the  knob  would  cause  the  individual  ele¬ 
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5. 6. 1.2  The  Graphical  Data  Space  as  its  own  Data  Diction 
ary 


A  conventional  DBMS  requires  the  use  of  a  data  dic¬ 
tionary  to  inform  the  user  of  the  structure  of  the  data¬ 
base.  Even  natural  language  user  interfaces  suffer  from 
the  problem  of  educating  the  user  as  to  what  queries  may 
be  answered  from  the  information  contained  in  the  data¬ 
base.  In  contrast,  the  graphical  data  space  of  SDMS  is 
its  own  data  description.  Rather  than  specify  a  relation 
and  attribute  name,  the  user  merely  traverses  the  data 
surface  until  he  reaches  the  desired  information,  at  which 
point  the  data  is  laid  out  in  front  of  him. 


5. 6. 1.3  Browsing 

The  user  of  an  SDMS  is  almost  always  presented  with  a 
display  which  gives  him  more  information  than  he  immedi¬ 
ately  needs.  Within  this  presentation,  finding  the 
required  information  is  facilitated  by  the  distinctive 
visual  qualities  which  can  be  imparted  to  the  data.  At 
the  same  time,  the  "unsolicited"  surrounding  data  makes  it 
possible  for  the  user  to  browse  through  the  database. 
This  is  a  difficult  activity  in  a  conventional  database 
system  where  every  piece  of  data  must  be' requested  expli¬ 
citly.  While  a  small  database  may  be  printed  out  and 
examined,  the  lack  of  any  mechanism  for  placing  related 
data  together  would  make  such  a  technique  impractical  for 
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very  large  databases.  Likewise,  it  would  be  very  tedious 
to  submit  repeated  queries  and  such  a  technique  would  be 
ineffective  if  the  user  was  not  already  familiar  with  the 
contents  and  structure  of  the  database. 

In  contrast,  SDMS  allows  the  database  administrator 
to  arrange  the  information  in  the  database  according  to 
any  chosen  attributes.  Once  the  user  has  positioned  his 
window  in  the  vicinity  of  the  data  being  sought,  he  can 
browse  through  the  surrounding  area,  letting  the  appear¬ 
ance  of  the  icons  (the  user  defined  graphic  representation 
of  the  data)  determine  where  he  focuses  his  attention. 


5. 6. 1.4  Using  Icon  Position  to  Convey  Information 

The  placement  of  a  particular  icon  can  be  used  to  aid 
in  recalling  a  particular  datum,  in  much  the  same  way  that 
a  person  finds  some  needed  information  in  his  office  by 
recalling  where  he  put  the  piece  of  paper  on  which  it  was 
written. 

The  placement  of  an  icon  may  also  convey  information 
directly.  For  instance,  the  location  of  each  ship  can 
indicate  its  nationality  and  type.  A  personnel  database 
could  be  arranged  according  to  seniority  or  salary.  Each 
of  these  organizations  could  be  displayed  in  a  separate 

part  of  the  graphical  data  space,  allowing  the  user  to 

i 

select  which  arrangement  suited  his  specific  query. 


He 
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could  then  observe  the  world-view  map  to  get  an  overall 
picture,  such  as  seeing  how  many  items  were  in  each 
category,  and  he  could  move  his  magnified  window  over  some 
particular  area  to  look  at  exceptional,  extreme,  or  aver¬ 
age  values. 


5. 6. 1.5  Graphic  Representations 

Graphic  representations  are  often  the  most  vivid 
means  of  conveying  information,  especially  for  aiding  in 
the  perception  of  trends  in  large  aggregations  of  data. 
The  most  familiar  form  of  this  technique  is  the  histogram 
or  the  graph,  where  numeric  data  is  displayed  in  graphical 
form.  The  graphical  output  facilities  of  SDMS  make  such 
display  of  numeric  data  possible  as  a  natural  extension  of 
the  system. 

Graphical  representations  may  also  be  used  to  advan¬ 
tage  in  displaying  trends  in  non-numeric  data.  For  exam¬ 
ple,  a  database  of  ships  could  be  displayed  against  the 
background  of  a  map,  with  the  wake  behind  each  ship  indi¬ 
cating  its  speed  and  direction.  With  each  display,  it 
would  be  easy  to  spot  trends  that  would  be  hard  to  formu¬ 
late  into  symbolic  queries,  such  as  a  large  number  of 
ships  heading  for  the  Middle  East. 


Automated  Support  for  Acquisition  Management  Page  -99- 

Some  Designs  to  Satisfy  Acquisition  Needs  Section  5 

5. 6. 1.6  New  Data  Types 

An  SDMS  is  not  restricted  to  data  that  originates  as 
numbers  and  character  strings.  The  raster  scan  output 
devices  and  digital  storage  of  graphical  data  provide  a 
natural  means  of  storing  images  such  as  photographs.  An 
optical  videodisk  can  be  controlled  through  SDMS  to  pro¬ 
vide  for  storing  a  very  large  number  of  video  images. 


5. 6. 1.7  Interface  to  a  DBMS 

An  SDMS  is  not  restricted  to  a  specific  DBMS.  The 
graphics  mechanism  is  superimposed  on  top  of  the  database 
management  system  and  therefore  requires  no  modification 
to  the  user's  original  symbolic  data,  allowing  SDMS  to  be 
used  to  access  an  existing  (possibly  shared)  database. 
Since  the  display  mechanism  is  external  to  the  database, 
it  is  possible  to  define  multiple  graphical  views  of  the 
same  data. 


5.6.2  Use  in  the  Acquisition  Community 

Like  the  database  management  system  described  in  sec¬ 
tion  5.2,  the  graphic  interface  provided  by  an  SDMS  can  be 
a  general  purpose  tool.  The  acquisition  community  can  be 
provided  with  one  standard  user  interface  for 


Page  -100-  Automated  Support  for  Acquisition  Management 
Section  5  Some  Designs  to  Satisfy  Acquisition  Needs 

.  accessing  information  in  a  database  (such  as  finan¬ 
cial  data,  budgets,  histories) , 

.  invoking  functions  that  use  data  (such  as  impact 
analysis  tools) , 

.  storing  information,  and 
.  accessing  communications  channels. 

This  standard  interface  would  provide  the  acquisition  com¬ 
munity  with  a  standard  framework  on  which  to  add  addi¬ 
tional  capabilities  according  to  need. 
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Letter  from  Admiral  A.J.  Whittle,  Jr.,  regarding  project 


DEPARTMENT  OF  THE  NAVY 
HEADQUARTERS  NAVAL  MATERIAL  COMMAND 
WASHINGTON.  D  C  20360 


Ser  00/54 
22  January  1980 


N  REPLY  REFER  to 


From:  Chief  of  Naval  Material 

Subj:  Acquisition  Management  Information  System;  development  of 
Enel:  (1)  Points  of  Contact 

1.  The  Naval  Material  Comnand  has  recently  initiated  a  task  to 
develop  an  Acquisition  Management  Information  System.  The  system  will 
probably  consist  of  numerous  modules  which  support  the  various  organi¬ 
zations  involved  in  acquisition  with  the  initial  emphasis  on  ships  and 
systems  installed  aboard  ship.  Accordingly,  the  modules  will  have 
many  users  at  various  levels  of  the  NMC. 

2.  The  Office  of  Naval  Research/Naval  Material  Command  (ONR/NAVMAT) 
Acquisition  Research  Council  has  contracted  with  two  companies,  ROH 
and  Computer  Corporation  of  America  for  the  system  architecture.  The 
development  procedure  will  require  that  the  personnel  of  these 
companies  visit  the  offices  of  your  activity  to  conduct  interviews, 
research  instructions,  investigate  organizational  and  reporting  rela¬ 
tionships  and  examine  information  flows  and  decision  making 
processes.  The  results  will  be  analyzed  and  a  specification  for 
system  development  prepared. 

3.  It  is  recognized  that  some  key  personnel  time  may  be  required 
during  interviews  and  the  possible  follow-up  discussions.  Therefore, 
the  interviews  will  be  requested,  via  written  correspondence, 
sufficiently  in  advance  to  minimize  disruption.  Points  of  contact  in 
NAVMAT  and  ONR  and  the  two  companies  are  listed  in  enclosure  (1). 

4.  The  cooperation  of  your  activity  is  requested.  The  success  of 
this  project,  in  part,  depends  on  the  assistance  received  and  the 
accuracy  of  the  information  provided. 


JR 


Distribution : 

COMNAVAIRSYSCOM 

COMNAVELEXSYSCOM 

COMNAVFACENGRSYSCOM 

COMNAVSEASYSCOM 

COMNAVSUPSYSCOM 


POINTS  OF  CONTACT 


L.  P.  Timmeney 
NAVMAT  (MAT  08D21) 

692-3127/8 

E.  Prentiss 
NAVSEA  (SEA  90) 

692-2750 

M.  Denicoff 
ONR  (ONR-437 ) 

692-4303 

R.  L.  Callahan 

ROH,  Incorporated 

2001  S.  Jefferson  Davis  Highway 

Suite  1105 

Arlington,  VA  22202 
(703)  920-7806 

R.  Winter 

Computer  Corporation  of  America 
575  Technology  Square 
Cambridge,  MA  02139 
(617)  491-3670 


ENCLOSURE  (1) 
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INSTRUCTION/ 

DIRECTIVE 

TITLE 

DATE 

0MB  Circular 

No.  A- 109 

Major  System  Acquisitions 

5 

Apr 

OFPP  Pamphlet  //I 

Discussion  of  Application  of  0MB,  Cir  A- 109 

Aug 

DDR&E 

Navy  Agreement  Concerning  Implementation  of 
DOD  Dir  5000.1  for  Ship  Programs 

11  Aug 

DOD  Dir  4105.68 

Procurement  Research 

22 

Jan 

DOD  Dir  4120.3 

Defense  Standardization  Program 

23 

Apr 

DOD  Inst  4140.41 

Government-Owned  Material  Assets  Utilized 
as  Government  Furnished  Material  for  Major 
Acquisition  Programs 

26 

Jul 

DOD  Dir  5000.1 

Major  System  Acquisitions 

19 

May 

DOD  Dir  5000.2 

Major  System  Acquisition  Process 

19 

Mar 

DOD  Dir  5000.3 

Test  and  Evaluation 

19 

Jan 

DOD  Dir  5000.19 

Policies  for  the  Management  and  Control 
of  Information  Requirements 

12 

Mar 

DOD  Inst  5000.22 

Guide  to  Estimating  Costs  of  Information 
Requirements 

17 

Oct 

DOD  Dir  5000.28 

Design  to  Cost 

23  May 

DOD  Dir  5000.30 

Defense  Acquisition  Executive 

20 

Aug 

DOD  Dir  5000.34 

Defense  Production  Management 

31 

Oct 

DOD  Dir  5000.35 

Defense  Acquisition  Regulatory  System 

8 

Mar 

DOD  Dir  5010.19 

Configuration  Management 

17 

Jul 

DOD  Dir  5030.8 

Office  of  the  Coordinator  for  Ship  Repair 
and  Conversion  for  the  Department  of  Defense 
and  the  Department  of  Commerce 

24 

Sep 

DOD  Dir  5030.9 

Coordination  of  Shipbuilding,  Conversion 
and  Repair  for  the  Department  of  Defense 

19 

Jan 

DOD  Dir  5100.62 

Clearance  of  Research  and  Studies  with 

Foreign  Affairs  Implications 

19 

Aug 

DOD  Inst  7000.2 

Performance  Measurement  for  Selected 
Acquisitions 

10 

Jun 

76 

76 

75 

77 

65 

74 

80 

80 

73 

76 

74 

75 

76 

77 

78 

68 

76 

72 

69 

77 
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INSTRUCTION/ 

DIRECTIVE 

TITLE 

DATE 

DOD  Inst  7000.3 

Selected  Acquisition  Reports  (SAR) 

23 

Sep 

75 

DOD  Inst  7000.10 

Contract  Cost  Performance,  Funds  Status 
and  Cost/Schedule  Status  Reports 

6 

Aug 

74 

DOD  Inst  7000.11 

Contractor  Cost  Data  Reporting  (CCDR) 

5 

Sep 

73 

DOD  Inst  7045. 7A 

Planning,  Programming  and  Budgeting  System 

29 

Oct 

69 

DOD  Dir  7200.4 

Full  Funding  of  DOD  Procurement  Programs 

30 

Oct 

69 
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INSTRUCTION/ 

DIRECTIVE 

SECNAVTMST  3900. 37A 

SECNAVTNST  4000. 29A 

SECNAVT2ET  4700.6 

SECNAVINST  5000. 1A 

SECNAVTNST  5000. 16D 


TITLE 


SECNAVTNST  5000. 25A 

SECNAVINST  5200.30 

SECNAVTNST  5200.32 

SECNAVINST  5250. 2A 

5ECNAVINST  5260. 1C 
SECIAVTET  5420.1723 

SECNAVTNST  7000. 14B 

SECNAVTNST  7000.153 
SECNAVTNST  7000.17A 
SECNAVINST  7000.13B 


Rapid  Development  Capability  for  Warefare 
Systems 

Development  of  Integrated  logistics  for 
Systems/Equipments 

Coordination  of  Shipbuilding,  Conversion, 
and  Repair  for  the  Department  of  Defense 

Systam  Acquisition  in  the  Department  of 
the  Navy 

Policy,  Roles,  and  Responsibilities  within 
Department  of  Navy  for  Implerentation  of 
the  CCD  Planning,  Programming  and  Budgeting 
System  (PPES) 

Procedures  for  Updating  Program  Data  in  the 
Five  Year  Defense  Program  (EYDP) 

Management  Decision  Coordinating  Papers 
(DC?)  and  Program  Memoranda  (PM)  within 
the  Department  of  the  Navy  (CN) 

Management  of  Embedded  Ccnputer  Resources 
in  Department  of  the  Navy  Systems 

Management  Studies  and  Analyses  Performed 
By,  or  For,  the  Department  of  the  Navy, 
Approval  of  Requesos  to  Contract  For 

Information  Requirements  Control 

Establishment  of  Department  of  the  Navy 
Systems  Acquisition  Review  Council  (DNSARC) 

Economic  Analysis  and  Program  Evaluation 
for  Navy  Resource  Management 

Contract  Cost  Performance,  Ponds  Status  and 
Ccst/Schedule  Status  Reports 

Performance  Measurement  for  Selected  Acquisi¬ 
tions 

Policy  for  the  Development  of  Financial 
Management  Systens  in  the  Department  of  the 
Navy 


-3 

B 

DATE 

27  Cct  71 

13  Jan  71 
22  May  72 
17  Nov  78 


8  Jan  70 

30  Jan  70 

27  Aug  75 

11  Jun  79 

19  Apr  79 

20  Cct  76 

18  May  76 

18  Jun  75 

5  Dec  74 
25  Apr  72 

12  Apr  77 


SECNAVINST  7000. 19B  Department  Cost  Analysis  Program 


12  Mar  75 
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SECMAVINST  7000.20 
SECMAVINST  7043. 2A 
SECNAVT2IST  7700. 5C 
SECMAVINST  7810.12 
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TITLE 

Contractor  Cost  Data  Escorting  (CCDR) 

Full  Funding  of  CCD  Procurement  Programs 

Selected  Acquisition  Escorts  (SAR) 

Progress  Payments  Based  on  Percentage  of 
Completion  for  Shipbuilding 


DATE 

10  Apr  74 
12  Dec  69 

16  Apr  76 

17  Jul  75 
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INSTRUCTION 

TITLE  DATE 

CNO  LTR 

Ser  97D1/159 

Joint  Navy/MARAD  Design  Team  19  Apr  73 

OP90  MEMO 

Staffing  Requirements  for  Major  (DCP)  4  Jan  77 

Acquisition  Programs 

OPNAVINST  3811. 1A 

Threat  Support  to  Weapon  System  Selection  30  Aug  78 

and  Planning 

OPNAVINST  3900. 22A 

Rapid  Development  Capability  for  Warfare  31  May  74 

Systems 

OPNAVINST  3960.10 

Test  and  Evaluation  22  Oct  75 

OPNAVINST  4100. 3A 

Department  of  the  Navy  Integrated  Logistics  6  Nov  72 

Support  (ILS)  System 

OPNAVINST  4700.8F 

Trials,  Acceptance,  Commissioning,  Fitting  24  Jun  72 

Out,  Shakedown  and  Post  Shakedown  Availability 
of  U.S.  Naval  Ships  Undergoing  Construction/ 

Convers ion/Mode  rni za t ion 

OPNAVINST  4720.9D 

Approval  of  Systems  and  Equipment  for  Service  23  Aug  74 
Use 

OPNAVINST  5000. 3 7A 

Management  and  Conduct  of  Studies  and  Analyses  20  Apr  79 

OPNAVINST  5000. 41B 

Pre-Defense  Systems  Acquisition  Review  Council  30  Mar  74 
(DSARC)  Procedures 

OPNAVINST  5000. 42A 

Weapon  Systems  Selection  and  Planning  3  Mar  76 

OPNAVINST  5000.46 

Decision  Coordinating  Papers  (DCPs) ,  Program  10  Mar  76 

Memoranda  (PMs)  and  Navy  Decision  Coordinating 

Papers  (NDCPs)  Preparation  and  Processing  of, 

OPNAVINST  5420. 53A 

General  Precept  for  the  Conduct  of  Trials  and  30  Mar  70 
Material  Inspections  of  Ships  and  Service  Craft 

OPNAVINST  5420.70 

Mission,  Organization,  and  Functions  of  the  2  Apr  71 

Board  of  Inspection  and  Survey 

OPNAVINST  7000. 17A 

Cost  Analysis  15  Sep  76 

OPNAVINST  7000.18 

Economic  Analysis  and  Program  Evaluation  for  27  Jul  73 

Navy  Resource  Management 

OPNAVINST  7043. 2B 

Reporting  Requirements  under  Title  10,  USC  16  Jul  76 

Section  139  (Congressional  Data  Sheets) 

OPNAVINST  7710.18 

Ship  Cost  Adjustment  Report  19  Jun  73 

OPNAVINST  9010.300 

Top  Level  Requirements  and  Top  Level  Specifi-  4  Jan  74 

cations  for  the  Development  of  Naval  Ships 
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INSTRUCTION/ 

NOTICE  TITLE  DATE 


NAVMATINST 

3900.13 

Preproduction  Reliability  Design  Review 

13 

Nov 

NAVMATINST 

3900.15 

Certification  and  Registration  for  Access  to 
D0D  Scientific  and  Technical  Information 
(located  DDC/NTIS  File) 

5  May 

NAVMATINST 

3910. 7B 

Planning  Procedures  for  the  Department  of 
the  Navy  Development  Program 

3 

Oct 

NAVMATINST 

4000. 2B 

Integrated  Logistic  Support  Planning  Policy 

27 

Jun 

NAVMATINST 

4000.29 

Basic  Principles  of  Logistics 

1 

Mar 

NAVMATINST 

4000.34 

Logistics  Support  Requirements  System 

15 

Jun 

NAVMATINST 

4000. 38A 

Standard  Integrated  Support  Management  System 

27  May 

NAVMATINST 

4130. 1A 

Configuration  Management 

i 

Jun 

NAVMATINST 

4330.37 

Should  Cost 

25 

Mar 

NAVMATINST 

4330.38 

Pricing  and  Overhead  Monitoring 

10 

Sep 

NAVMATINST 

4341.1 

GFM  for  Major  Acquisition  Programs 

27 

Jun 

NAVMATINST 

5000. 18A 

HQ  Naval  Material  Command  Participation 
Relative  to  DSARC 

12 

Mar 

NAVMATINST 

5000. 19B 

Weapon  Systems  Acquisition  Program  Review 

24 

Jun 

NAVMATINST 

5000. 19C 
(Prop) 

Appraisal  Within  NMC 

NAVMATINST 

5000.22 

Weapon  System  Selection  and  Planning 

14 

Jan 

NAVMATINST 

5000.23 

Defense  Systems  Acquisition  Review  Council 
(DSARC) 

20 

Mar 

NAVMATINST 

5000 . 26 

Onsite  Project  Manager  Representative 

17 

Feb 

NAVMATINST 

5000.27 

Evaluation  of  the  Systems  Acquisition  Process 

2 

Mar 

NAVMATINST 

5040 . 2 A 

Project  Management  Reviews 

11 

Feb 

NAVMATNOTE 

5200 

NAVMAT  Selected  Acquisition  Tracking  System 
(NSATS) 

22 

Jan 

NAVMATINST 

5200.11B 

Project  Master  Plan 

22 

Jul 

NAVMATINST 

5200. 14B 

Management  Information  and  Data  Systems 

17 

Nov 

75 

77 

74 

75 

68 

71 

77 

74 

74 

74 

75 

74 

74 

75 

75 

76 

76 

72 

79 

74 

71 
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CATS 


NA.VMPC2CST  5  4  C  0 . 1 4 


Ship  Life  Cycle  Management,  Objectives 
ard  Policies  for 


7  Apr  69 


NAVMATHiST  5430.60 


HQ  Naval  Material  Germane  (HQNAVMAT ) 
Manual 


Grcanizaticn 

10  Jul  78 


NAVMATINST  7000.143 
NAVMATDST  7 0  0 0 . 1 7C 


Management  within  NMC  tor  Snip  Cevelcprren >- 
Acquisition/Conversion  Projects 

Contractor  Cost  Performance  Measurement 


MAVMATUST  7000. 19A  Cost  Analysis  Program 

NAVMAIINST  7000.20  Contractor  Cost  Performance  and  Ponds 


NAVMATINST  7000.23 


Contractor  Cost  Data  Escorting 


30  Jul  71 
30  Jan  74 
30  Jul  76 
15  Jun  73 
9  Dec  74 


NAVMAT 

P-5240 

P-5241 

P-5242 

P-5243 
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title  date 

C/S CSC  Joint  Implementation  Guide  1  Oct  76 
Contractor  Cost  Data  Reporting  (CCDR)  System  5  Nov  73 
Joint  Cesicn-Tc-Gost  Guide  3  Oct  73 
C/SCSC  Joint  Surveillance  Guide  1  Jul  74 
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NAVSEAINST  3900. 2A 

NAVSEAINST  3900.6 

NAVSEAINST  3960.1 

NAVSEAINST  3960.2A 
NAVSEAINST  4105.1 

NAVSEAINST  4120.3 

NAVSEAINST  4121.1 

NAVSEAINST  4130.1 

NAVSEAINST  4130.10 

NAVSEAINST  4200. 1A 
NAVSEAINST  4200. 8A 

NAVSEAINST  4205.1 

NAVSEAINST  4340.1 

NAVSEAINST  4341.2 

NAVSEAINST  4355.4 

NAVSEAINST  4370. 1A 
NAVSEAINST  4441.1 


title  date 

Manpower,  Personnel,  and  Training  Support  for  19  Aug  75 
NAVSEA  -  Cognizant  Ship,  System,  Equipment, 
and  Non-Hardware  Developments 

Reliability  and  Maintainability  Program  of  18  Apr  79 

the  Naval  Sea  Systems  Command  for  Design, 

Development  and  Acquisition  (Non-Nuclear) 

Assignment  of  NAVSEA  Research  and  Development  27  Jul  77 
Work  to  Shore  Activities 


Total  Ship  Test  Program  for  Ship  Production  9  Sep  76 
(TSTP/SP) ,  Implementation  of 

Test  and  Evaluation  2  Nov  78 


Integrated  Logistics  Support  (ILS) ,  Policy,  22  Jul  77 
Responsibilities,  and  Planning 

Defense  Standardization  Program  (DSP)  Within  10  May  77 
the  Naval  Sea  Systems  Command 

Ship  Specifications,  Preparation,  Review,  9  Apr  77 

and  Revision  of 


Record  of  Chances  (ROC) /Shipbuilding  and  16  Oct  74 

Conversion  Navy  (SCN) , 

Configuration  Control  Board  Operations  for  20  Sep  78 
Systems  and  Equipments,  Establishment  of 

NAVSEA  Contractor  Procurement  Review  Program  1  May  78 


NAVSEA  Contractor  Support  Services  and  Sole  7  Mar  79 

Source  Contracts,  Review,  Management,  and 
Control  of 


Approval  for  Procurement  of  Development  by  1  Oct  74 

Fixed  Price  Type  Contracts 

Government  Furnished  Information  (GFI)  14  Jan  76 

Management  System 

Policy  on  Government  Furnished  Material  for  25  Feb  77 
New  Construction  and  Conversion  Projects 


Quality  Evaluation  Test  Sample  Provisions,  18  Mar  77 

Policy  for 

Contract  Terminations,  Administration  of  21  Sep  77 


Fleet  Logistic  Support  Improvement  Program  11  Sep  76 
(FLSIP)  Coordinated  Shipboard  Allowance  Lists 
(C0SAL)  for  Construction,  Major  Conversion, 
and  Overhaul 
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NAVSEAINST  4441. 
NAVSEAINST  4720. 

NAVSEAINST  4720. 

NAVSEAINST  4720. 

NAVSEAINST  4800. 
NAVSEAINST  4855 

NAVSEAINST  5000 
NAVSEAINST  5000 
NAVSEAINST  5100 

NAVSEAINST  5200 

NAVSEAINST  5200 

NAVSEAINST  5200 
NAVSEAINST  5220 
NAVSEAINST  5230 

NAVSEAN0TE  5400 

NAVSEAN0TE  5400 
NAVSEAINST  5400 
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TITLE 


8  Allowance  Lists  for  Boats  and  Landing  Craft, 
Policies,  and  Procedures  Governing 

12A  Supply  Support  of  the  Operating  Forces 

1A  Approval  for  Service  Use  for  Systems  and 
Equipment 

3  Fleet  Modernization  Program,  Policies, 
Procedures,  and  Responsibilities 

11  Shipboard  Installations  and  Modifications 
Performed  Outside  the  Formal  FMP  Process, 
Centralized  Control  of 

1  Manufacturing  Technology  Program 

,24  NAVSEA  Acquisition  Product  Quality  Program 
Evaluations 

.  1  Navy  Department  Studies,  Coordination  of 

,2  Onsite  Project  Manager  Representative  (PMR) 

,12  System  Safety  Program  for  Ships,  Shipbome 
Systems  and  Subsystems,  and  Equipment, 
Requirements  for  Implementation  of 

NAVMAT  Selected  Acquisition  Tracking  System 
(NS ATS) 

,  2A  Reporting  Requirements  to  the  Naval  Material 
Command  Center 

.4  Project  Master  Plans 

,4A  Tasking/Funding  NAVSEC,  Washington,  D.C. 

. 6A  Procedures  and  Requirements  for  MIS  and 
Data  Systems  (Cross  Reference  NAVSEA  ADP 
Info  Book) 

Principle  Deputy  Commander  for  Acquisition 
(SEA90) ,  Assignment  of  Additional  Responsi¬ 
bilities 

Reorganization  of  NAVSEASYSC0M 

. 1A  NAVSEASYSCOM  Headquarters  Organization  Manual 

.12  Surface  Weapon  System  Test  and  Evaluation 
Responsibility,  Assignment  of 


DATE 

9  Aug  7  3 

17  Feb  78 

7  Nov  75 

15  May  79 

30  May  78 
13  Dec  77 

28  Jul  75 
24  May  76 

16  May  78 

(Proposed) 

7  Jun  76 

7  Nov  75 
21  Sep  78 
12  Apr  78 

8  Apr  79 

9  Apr  79 

18  Jul  77 


20  Mar  75 
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5400. 17A 

Charter  for  the  Combatant  Craft,  Service 

Craft  and  Emphibian  Acquisition  Project 
(PMS  300) 

15 

Aug 

77 

NAVSEAINST 

5400.27 

Procedures  Governing  the  Transfer  of  Manage¬ 
ment  Responsibility  for  Ships  Between 

SHAPM's  and  SLM's 

6 

Apr 

76 

NAVSEA fNST 

5400.43 

Program  Managers  in  Design  Division,  Criteria 
for  Establishment  of 

2 

Mar 

77 

NAVSEAINST 

5420. 18B 

NAVSEA  Executive  Board 

16 

Jul 

79 

NAVSEAINST 

6240. 1A 

Environmental  Quality  Program 

20 

Dec 

77 

NAVSEAINST 

7000.3 

Ship  Project  Directive  System,  Implementation 
of 

30 

Jul 

75 

NAVSEAINST 

7000. 4A 

Cost/Schedule  Control  System  Implementation 
and  Surveillance 

7 

Dec 

77 

NAVSEAINST 

7100.4 

General  Guidance  for  the  Budget  and  Apportion¬ 
ment  Submission  in  Support  of  NAVSEA  Programs 

13  Apr 

76 

NAVSEAINST 

7110.1 

Training  Support  Funding  Responsibilities  in 
NAVSEASYSCOM 

4 

Feb 

75 

NAVSEAINST 

7300. 1A 

Navy-Wide  Standard  Document  Number  and  Account¬ 
ing  Classification  Reference  Number  (ACRN) 

-  8 

Dec 

77 

NAVSEAINST 

7300.10 

Classification  of  Cost  Estimates 

24 

Aug 

78 

NAVSEAINST 

7300.13 

NAVSEA  Cost  Estimating  and  Analysis  Program 
for  GFM 

23 

Jan 

80 

NAVSEAINST 

7301.6 

Administrative  and  Operating  Procedures  for 
Program  Review  System  (PRS) 

1  Apr 

75 

NAVSEAINST 

7301.22 

Shipbuilding  and  Conversion,  Navy  Appropriation  15  Dec  77 
Procedures  for  Financial  Managements  of 

NAVSEAINST 

7700.1 

Selected  Acquisition  Report 

11 

Jun 

76 

NAVSEAINST 

9060.1 

Top  Level  Specifications  (TLS)  for  New  Ship 
Design 

6  May 

75 

NAVSEAINST 

9060.2 

Design  to  Cost  Guide  for  Ship  Acquisition 

24 

Jul 

75 

NAVSEAINST 

9060.3 

Ship  Acquisition  Plan  Outline  and  Ship 
Acquisition  Plan 

24 

Nov 

75 

NAVSEAINST 

9060.4 

Ship  Acquisition  Process 

29 

Mar 

76 
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Ship  Acquisition  and  Logistic  Support,  Combat  29  Mar  76 
System  Design  Requirements  and  Combat  System 
Operational  Design 


Ship  Models,  Procurement  of  15  Aug  75 

Procedures  and  Responsibilities  for  15  Sep  78 

Certification  of  Aviation  Facilities  in 
Naval  Ships  Operating  Aircraft 


Models  and  Mock-ups  of  Shipboard  Spaces  and  24  Apr  78 
Systems  (Except  for  Nuclear  Propulsion  Plan 
Spaces) ;  Procedures  and  Inspecting  Require¬ 
ments  for 


U.S.  Navy  Main  Propulsion  Steam  Generating  21  Dec  77 
Plan  Inspection  and  Certification  Program 
(Nuclear  Excluded) ;  Responsibilities  for 

Sewage  Systems  on  U.S.  Navy  Surface  Vessels,  15  Nov  78 
Certification  Program  for 
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Naval  Sea  Systems  Command  Report  on  Funding  in  Support  of  the  Automatic 
Data  Processing  Equipment  (ADPE)  Modernization  Program  25  Jun  79 

Naval  Sea  Systems  Command  Automated  Management  Information  Systems  2  Mar  79 

Naval  Sea  Systems  Command  ADP  MIS  Plan  (Identification  of  Users 
Objectives  and  Functional  Requirements) 

Naval  Sea  Systems  Command  Handbook  of  Procedures  and  Requirements 
for  Management  Information  and  Data  Systems  (NAVSEAINST  5230. 6A) 

Selected  Acquisition  Reports  (SAR)  System  Functional  Description  22  May  79 

Naval  Sea  Systems  Command  Master  Acquisition  Control  Register  Jun  79 

Specification  for  the  Development  of  a  NAVSEA  Data  Base 
Dr.  F.  Frisch 


6  Oct  78 
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Acquisition  Management  -  Presentations  that  describe  briefly: 
o  Financial  Reporting  and  Information  Requirements 
o  Cost  Performance  Reporting  and  Baseline  Management 
o  Cost/Schedule  Status  Report  (C/SSR) 


o  Cost/Schedule  Control  Systems  Criteria 

Progress  Report  to  the  Congress  1976  on  Cost  Accounting  Standards  Board 

Naval  Sea  Systems  Command  Monthly  Progress  Report  for  Shipbuilding 
and  Conversion 

The  Naval  Material  Command  Manpower  Requirements  Model  by 
MANTECH,  INC. 


1  Aug  79 

Jun  78 


Information  for  Navy  Witnesses  Appearing  before  Congressional 
Committees 


Jan  78 


MIL-STD-1679  Weapon  System  Software  Development 


1  Dec  78 
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"Government  Procurement  Policy: 
B.  R.  Lenk 


A  Survey  of  Strategies  and  Techniques" 

21  Mar  77 


"Annual  Report  on  the  Status  of  the  Shipbuilding  and  Ship  Repair  Industry 
of  the  United  States  1976"  APr  77 

"Management  Update:  Navy  Major  System  Acquisitions" 

Don  Sowie  Associates,  Inc.  8eP  77 


"A  General  Technique  for  R&D  Cost  Forecasting" 

W.  J.  Weida  SeP  77 


"Ship  Acquisition  Research" 

M.  Denicoff 

"The  Naval  Ship  Acquisition  Process  as  a  System" 

S.M.  Dean,  C.R.  Jones,  and  M.G.  Sovereign 

"Report  of  the  Acquisition  Cycle  Task  Force" 

Defense  Science  Board  1977  Summer  Study 

"A  Preliminary  Review  of  the  United  States  Shipbuilding 
Industry  and  its  Ability  to  Support  the  United  States  Navy" 

J.  D.  Morgan 

"The  Profitability  of  the  U.S.  Shipbuilding  Industry  1947-1976" 
E.  M.  Kaitz 


1976 

Feb  78 

15  Mar  78 


May  78 


20  Jun  78 


"Escalation  Clauses  in  Shipbuilding  Contracts" 

J.  D.  Vellis ,  II  Jun  78 

"Investigation  of  Implementation  of  D0D1  7000.2,  Contractor 
Reporting  Criteria" 

Log/An,  Inc.  Undated 

"Conceptual  Analysis  for  the  Development  of  an  Acquisition 
Information  System" 

International  Applied  Science  and  Technology  Associates,  Inc.  Mar  79 


"Recommendations  of  Naval  Shipbuilding  Committee,  Shipbuilding 
Council  of  America,  Pertaining  to  Long  Range  Naval  Shipbuilding" 

Shipbuilders  Council  of  America  5  Mar  79 

"Costing  Methods  and  Models  for  Acquisition  Planning,  Budgeting, 
and  Contracting" 

Office  of  Federal  Procurement  Policy,  Fed  Acquisition  Institute  Apr  79 


"Introducing  a  Formal  Strategic  Planning  System  in  a  Business  Firm" 

A.  C.  Hax  and  G.  Schulmeyer  dun  79 

"Final  Report  for  Research  on  Mergers,  Conglomerates,  and  Diversification" 

A.  C.  Hax  Dec  79 
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"Some  Acquisition  Strategy  Implications  Drawn  from  a  Theoretical 
Examination  of  the  Front  End  of  the  Process" 

A.  Stuart  Atkinson 

"Affordability  -  Not  a  Dirty  Word" 

RADM  L.  S.  Kollmorgen,  USN 

"The  DOD  Affordability  Policy" 

T nix ton  R.  Baldwin 

"Improving  the  Acquisition  System" 

Dr.  Robert  J.  Massey,  Gordon  A.  Smith,  and  Jack  F.  Witten 

"Estimation  and  Analysis  of  Navy  Shipbuilding  Program  Disruption  Costs 
CAPT  Colin  Hammon,  USN;  Dr.  David  R.  Graham 

"Contract  Negotiations  Via  Closed-Circuit  Television" 

Joseph  C.  Groth 

"Second  Sourcing  in  Major  System  Acquisitions" 

LCDR  D.  S.  Parry,  SD,  USN;  LCDR  B.  R.  Sellers,  SC,  USN 

"Use  of  Fixed  Price  Incentive/ Award  Fee  Contracts  for  the  Construction  of 
Follow  U.S.  Navy  Ships" 

Dr.  Arthur  C.  Meiners ,  Jr. 

"Enhancement  of  Competition  in  the  Department  of  Defense" 

Daniel  D.  Unruh 
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"Computer  System  Emulation  Technology  Assessment  for  AN/UYK-5  Replacement  Program 
Naval  Ocean  Systems  Center,  San  Diego,  CA  1  Feb  79 

"Formal  Design  and  Analysis  of  Distributed  Data  Processing  Systems" 

Dr.  Donald  R.  Fitzwater  79 


"System  Level  Concurrency  Control  for  Distributed  Data  Base  Systems" 
D.  J.  Rosenkrantz,  R.  E.  Stearns,  P.  M.  Lewis 


"A  High-Speed  Parallel  Data  Link  Between  Co.  Resident  Mini  Computers" 
E.  C.  Demone 


Jun  79 


"Military  Program  Management:  A  Guide  to  Wonderland" 

H.  L.  McKinley,  Air  War  College  APr  78 

"Analysis  of  the  Guided  Missile  Frigate  (FFG-7  Class)  Ship 
Acquisition  Project" 

J.  D.  Brotherton,  NPS  Monterey  Mar  79 
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Lead  Ship  Analysis  on  FFG-7,  DD-963,  AO-177  &  CGN-38  for  GFE,  GFI , 

Production  Working  Drawings  and  Labor  Progress 

NAVSEA  Position  Papers  on  Naval  Ship  Procurement  Process  Study 
o  Industrial  Input  to  Budget 
o  Class  C  Budget  Submittals 
o  Supporting  Industry  Base 
o  Progress  Payments 
o  Validated  Drawing  Effectiveness 
o  Stable  Shipbuilding  Program 
o  Workload  Window 


Naval  Ship  Procurement  Process  Study  Final  Report 


Jul 
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Unitpd  States  General  Accounting  Office  Report  LCD-79-113 
Duplication  in  the  Navy's  Management  Information  Systems 

TRANSIM  -  A  General  Purpose  Problem  Solving  Tool 
D.  L.  McMicheal,  B.S.  Orleans 
Naval  Engineers  Journal 

Risk  Management  Keeps  Aircraft  Carrier  Overhaul  Planning  on  Schedule 
G.  F.  Jurges 
Naval  Engineers  Journal 


Oct  73 


Oct  73 


Production  and  Construction  -  A  Comparison  of  Concepts  in  Shipbuilding 
and  Other  Industries 

Dr.  F.  Frisch  3ul  76 


FY  80  NAVSEA  Tiger  Team  Information 
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ONR/NAVMAT 

System  Acquisition  Schedule  Milestones  (SESCO) 

Guidance  for  SHAPM's 

FFG-7  Class  Validated  Drawing  Program 

The  Concept,  Worth,  and  Applicability  to  Future  Programs 

Need  for  a  Macroeconomic  Approach  to  Supplement  the  Current 
Navy  Resource  Allocation  Process 
CDR  Rolf  Clark 

Navy  Initiated  Changes  Planned  or  Underway  to  Copy  with  Shipbuilder 
Delay  and  Disruption 
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Descriptions  of  Existing  or  Developing  Management  Systems 
Specific  Ship  Acquisition  Projects 

Information  Management  Procedures 

for  Processing  Contractor  Submittals 
for  Additional  Consideration 
(LHA-Class  Claims  Documentation) 

PMS-383  Management  Information  System 
Description  SD01 

PMS-400  AEGIS  Management  Information  System 
Major  Surface  Combatant  Ship  Project  (PM  18) 

Management  Information  Baselines 
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MANUALS,  HANDBOOKS,  MILSTD 

Ship  Life  Cycle  Management  Manual,  0900-054-9010  Oct  69 

Top  Level  Specification  Handbook  APr  '5 

Fitting-Out  Management  Information  System,  General  Requirements 
MIL-STD  1626  (Ships) 


Jun  74 
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C .  How  to  Read  an  SADT  Model 

This  section  describes  how  to  read  an  SADT  model.  Only 
those  features  of  SADT  used  in  this  document  are  described. 


C. 1  SADT  Is  for  Understanding  Systems  Via  Modeling 

SADT  is  a  techniaue  that  enables  people  to  understand 
complex  systems,  and  enables  them  to  communicate  their  under¬ 
standing  to  others. 

As  used  here,  a  "system"  may  be  defined  as  any  combination 
of  machinery  (hardware) ,  data  and  people,  working  together  to 
perform  a  useful  function.  SADT  may  be  applied  in  planning, 
analvsis,  design,  nroiect  management,  or  whenever  a  documented 
understanding  of  a  complex  subject  is  useful.  The  result  of 
applying  SADT  is  a  "model"  that  shows,  in  a  series  of  diagrams 
the  understanding  gained. 

In  order  to  completely  describe  a  given  system,  several 
models  may  be  needed,  each  expressing  a  particular  viewpoint. 

In  analyzing  a  system,  it  is  often  easier  to  study  and  describe 
a  system  from  several  viewpoints  (to  be  reconciled)  than  to 
force  one  viewpoint  on  the  analysis.  In  this  project,  for 
example,  four  models  were  developed: 
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Model  Name 


Content 


Viewpoint 


PROJ 


Describes  project 
activities 


Ship  Acquisition  Mgr. 


PMS 


Describes  project 
management 


Acquisition  Mgr. 


MATO  8 


Describes  assessment  MATO 8 
of  projects 


SEA90 


Describes  advising  SEA90 

acquisition  manage¬ 
ment 


Each  of  these  models  is  identified  by  its  Model  Name. 
These  are  used  in  node  numbers  and  reference  numbers,  to  be 
described  shortly. 

C. 2  "Top-Down"  Organization  of  the  Model 

The  diagrams  in  a  model  are  organized  in  a  hierarchic 
and  modular  "top-down"  fashion,  showing  the  breakdown  of  the 
system  into  its  component  parts.  Application  of  SADT  starts 
with  the  most  general  or  abstract  description  of  the  system  to 
be  produced.  If  this  description  is  contained  in  a  single 
"module",  represented  by  a  box,  that  box  is  broken  down  into  a 
number  of  more  detailed  boxes ,  each  of  which  represents  a 
component  part.  The  component  parts  are  then  detailed,  each 
on  another  diagram.  Each  part  shown  on  a  detail  diagram  is 
aaain  broken  down,  and  so  forth,  until  the  system  is  described 
to  any  desired  level  of  detail.  Lower  level  diagrams,  then. 
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are  detailed  breakdowns  of  higher  level  diagrams.  At  each 
stage  of  breaking  down  the  system,  the  higher  level  diacrram 
is  said  to  be  the  "parent"  or  overview  of  the  lower-level 
"detail"  diagrams. 


C. 3  Diagrams  are  Indexed  by  Node  Numbers 

In  an  SADT  diagram,  the  component  parts  are  shown  as 
numbered  boxes.  A  diagram  may  have  no  more  than  six  boxes. 
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Each  box  is  detailed  in  one  diagram  at  the  next  lower  level 
until  a  sufficient  level  of  detail  is  reached. 

The  place  of  each  diagram  in  a  model  is  indicated  by  a 
"node  number",  derived  from  the  numbering  of  boxes.  For  ex¬ 
ample,  A21  is  the  diagram  which  details  box  1  on  the  A2  diagram. 
Similarly,  A2  details  box  2  on  the  AO  diagram,  which  is  the 
top  diagram  of  the  model.  This  hierarchy  may  be  shown  in  an 
index  of  diagram  names  and  their  node  numbers  called  a  "node 
index" .  The  node  index  serves  as  a  table  of  contents  for  a 
model . 


When  multiple  models  are  used,  as  is  the  case  here,  the 


node  number  includes  the  model  name,  as  in  PMS/Al. 


C. 4  Diagrams  Consist  of  Labeled  Boxes  and  Arrows 

In  SADT,  boxes  represent  components  in  the  breakdown,  and 
arrows  represent  relationships  between  these  components.  De¬ 
scriptive  labels  are  written  inside  each  box  and  along  each 
arrow  to  describe  their  meaning.  The  notation  is  ker>t  simple 
to  permit  easy  reading  with  little  special  training. 

The  following  is  a  sample  SADT  diagram.  Notice  that  the 
boxes  represent  the  breakdown  of  activities  or  functions  performed 
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by  the  system  and  are  named  by  verbs.  Arrows,  which  represent 
objects  or  information,  are  labeled  with  nouns.  As  a  variation 
of  standard  practice,  boxes  here  will  have  a  reference  number 
below  them  to  correlate  their  use:  (1)  in  a  diagram;  (2)  in 

the  discussion  (in  earlier  sections);  and  (3)  on  their  detailing 
diagram  (node  number) .  This  reference  number  is  the  same  as 
the  node  number  of  the  diagram  that  decomposes  that  box  (whether 
or  not  that  diagram  has  been  produced  yet) . 
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C.5  Box  and  Arrow  Syntax 


The  sample  SADT  diagram  shows  that  the  descriptive 
names  and  labels  convey  the  box  and  arrow  contents  to  the 
reader . 


In  addition  to  its  label,  the  side  at  which  an  arrow 
enters  or  leaves  a  box  shows  its  role  as  an  input,  control, 
output,  or  mechanism  for  the  box. 


Control 


1 


Input 

PERFORM 

Output 

ACTIVITY 

I  Reference  # 
Mechanism 


Inputs  (on  the  left)  are  transformed  into  outputs 
(on  the  right) .  Controls  (on  the  top)  govern  the  way  the  trans¬ 
formation  is  done.  Mechanisms  (on  the  bottom)  indicate  the  means 
by  which  the  function  is  performed.  A  "mechanism"  might  be  a 
person  or  a  committee  or  a  machine  or  a  process. 
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Ship 

Design 


Electronic 


uyo  101 1  io, 

Steel, 

Paint 

BUILD  A 

Ship 

SHIP 

i 

!  SHIPB/AO 

Shipyard 

Arrows  represent  single  things  or  general  classes  of 
objects  or  information.  The  arrow  label  describes  what  the 
arrow  represents. 

The  arrow  structure  of  an  SADT  diagram  represents  a 
constraint  relationship  among  the  boxes.  It  does  not  represent 
flow  of  control  or  sequence.  The  arrows  entering  a  box  show  all 
that  is  needed  by  the  box  to  perform  its  function.  Therefore, 
the  box  is  constrained  by  its  input  and  control  arrows. 

An  output  of  one  box  may  satisfy  some  or  all  of  the 
input  or  control  conditions  required  by  one  or  more  other  boxes. 

It  is  not  necessary  that  each  and  every  box  have  input  and  control 
and  output.  Also,  several  boxes  can  be  performing  their  functions 
simultaneously . 
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Arrows  may  branch  or  be  joined.  The  branches  may  each 
represent  the  same  thing,  or  different  things  of  the  same 
general  type. 
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C.6  Arrows  Show  the  Connection  between  Parent  and  Detail  Diagram 


Some  arrows  show  both  their  source  and  destination  boxes 
on  the  same  diagram,  while  other  arrows  have  one  end  unconnected. 


The  unconnected  arrows  represent  inputs,  controls,  or  outputs 
of  the  parent  box.  To  find  the  source  or  destination  of  these 
unconnected  arrows ,  the  reader  must  locate  the  matching  arrows 
on  the  parent  diagram.  All  such  unconnected  arrows  must  continue 


"UNCONNECTED" ARROWS 
ARE  DERIVED  FROM  THE 
"PARENT" 


THE  MATCH  MUST 
BE  COMPLETED  AND 
CONSISTENT 


Parent 

Diagram 


Detail 

Diagram 


This  arrow  is  < 
an  input  from 
the  parent 


This  arrow  is  a 
control  from  the  parent 
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on  the  parent  for  the  diagrams  to  be  complete  and  consistent. 

In  very  special  cases,  an  unconnected  arrow  on  a  detail 
diagram  has  no  matching  arrow  on  its  parent,  or  vice  versa. 

In  this  cast1,  the  arrow  head  or  tail  is  shown  enclosed  in 
parentheses . 


No  match  shown  on  detail  No  match  shown  on  parent 

diagram  for  these  arrows  diagram  for  these  arrows 


An  example  of  using  this  notation  is  shown  on  Diagram  PMS/A-0, 
for  the  fourth  control  arrow  "Acquisition  Policy".  In  this 
case,  acquisition  policy  is  clearly  needed,  but  showing  its 
detailed  use  is  not  important  to  understanding  lower  level 
diagrams . 


C. 7  How  to  Explore  a  Model 


SADT  models  may  be  used  as  a  reference,  providing  all 
details  of  a  particular  subject,  or  as  a  tutorial,  providing 
an  overview  of  the  whole  system.  To  read  the  model  for  its 
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overview,  use  the  node  index  to  find  all  high-level  diagrams. 
Disregard  detail  diagrams.  For  example,  an  overview  is  ob¬ 
tained  as  described  above  by  studying  A-0,  AO,  Al,  A2,  and  A3. 

To  read  the  model  for  reference ,  use  the  index  to  find 
all  diagrams  detailing  the  subject  of  interest.  Disregard 
unrelated  diagrams. 


C . 8  Diagram  Binding  Order 

When  published,  the  diagrams  in  a  model  are  bound  in 
"node  number"  order.  That  is,  all  detail  diagrams  relating  to 
one  box  on  an  overview  diagram  are  presented  before  the  next 
overview  diaaram  and  its  detail.  This  order  places  related 
diagrams  toaether  and  follows  the  order  of  the  node  index 
table-of-contents . 


C . 9  Systematic  Diagram  Reading  Steps 

The  precise  information  about  a  system  is  in  the  diagrams 

themselves.  The  following  reading  sequence  is  recommended: 

1.  Scan  only  the  boxes  of  the  current  diagram  to  gain 
a  first  impression  of  the  decomposition. 
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2.  Using  the  parent  sketch  as  a  quide,  rethink  the 
message  of  the  parent.  Note  how  the  arrows  feeding 
to  and  from  the  appropriate  box  reappear  in  the 
current  diagram. 

3.  Then,  consider  the  internal  arrows  of  the  current 
diaqram  to  see  how  it  works  in  detail.  Consider 
the  boxes  from  upper  left  to  lower  riaht.  Examine 
the  arrows  bv  goinu  clockwise  around  each  box. 

Check  the  storv  being  told  by  the  diagram,  bv  con¬ 
sidering  how  familiar  situations  are  handled. 


This  sequence  becomes  quite  natural  and  ensures  that  the  major 
features  of  each  diagram  receive  attention.  The  reader  should 
find  that,  with  a  little  concentration,  the  diagrams  are  not 
difficult  to  read. 
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1.  INTERVIEW  METHODOLOGY 

Over  40  upper  and  middle  level  managers  were  interviewed  in  order 
to  establish  the  scope  of  the  efforts  required  to  provide  improved 
acquisition  management  information  support.  The  objectives  of 
these  interviews  were  to  obtain  from  each  respondent  his  perception 
of  the  acquisition  environment ( s) ,  his  definition  of  the  acquisition 
functions  with  which  he  was  concerned,  and  to  determine  his  concerns 
and  goals  relative  to  his  function  and  those  functions  closely 
related  to  his,  or  about  which  he  was  particularly  well  informed. 
Through  a  series  of  meetings  with  members  of  the  Steering  Committee 
and  other  key  figures  in  the  Naval  Material  Command  and  the  Office 
of  Naval  Research,  interview  guidelines  and  questions  were  developed 
to  elicit  the  desired  information.  The  interview  questions  used 
during  this  phase  of  the  project  were  purposely  broad  and  general, 
so  as  to  avoid  narrowly  channelling  the  interviewee's  thinking. 

The  emphasis  was  on  discovery,  with  minimal  "leading  of  the  witness  . 

After  the  interviews  began  it  was  quickly  discovered  that  the 
questions  being  asked  were  not  yielding  the  kinds  of  responses  which 
would  satisfy  the  stated  objectives.  Consequently,  over  the  periods 
of  time  the  interviews  were  being  conducted,  the  guidelines  and 
questions  were  iteratively  enhanced  to  obtain  more  meaningful  respon¬ 
ses  or  to  take  into  account  the  particular  interest  or  experience 
of  the  interviewee.  Further,  respondents  were  encouraged  to  vol¬ 
unteer  their  own  ideas  and  concerns  in  a  more  informal  manner.  The 
evolution  of  the  interview  questions  is  apparent  in  the  series  of 
interview  guidelines  and  questions  which  are  presented  in  Attachments 
1,  2,  3,  and  4  hereto  in  the  sequence  in  which  they  were  developed. 

The  later  interviews  were  permitted  to  take  the  form  of  a  more 
loosely-structured  dialogue  with  interviewers  asking  follow-up, 
open-ended  questions  after  initial  informal  statements  by  the  managers 


Page  E-2 


being  interviewed.  A  stronger  emphasis  was  placed  on  obtaining 
from  interviewees  their  perception  of  what  are  the  "soft  spots"  in 
the  acquisition  process.  This  approach  yielded  much  better  results. 
Considerable  information  about  the  functions  and  concerns  of  a 
sample  set  of  contemporary  acquisition  managers  was  gained  through 
this  reduction  in  formality.  However,  the  resulting  accumulation 
of  data  was  rendered  less  amenable  to  a  structured  tabulation  than 
would  have  been  the  case  if  a  set  of  standard  questions  had  been 
rigidly  adhered  to. 

All  interviews  were  conducted  on  a  not-f or-attribution  basis  so  that 
candid  responses  would  be  obtained.  Consequently,  specific  indivi¬ 
duals  are  not  connected  with  specific  interview  responses  herein. 

In  order  to  intelligently  discuss  current  functions  with  interviewee 
and  to  ensure  that  no  significant  current  acquisition  process  func¬ 
tions  were  overlooked,  the  list  of  acquisition  functions  in  Figure 
1  was  developed.  It  is  an  attempt  to  define  the  functions  or 
disciplines  which  are  collectively  referred  to  as  the  "acquisition 
process" . 
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01  LIFE  CYCLE  COSTING  (LCC) 


02  DESIGN  TO  COST 
03  INDUSTRIAL  CAPACITY  ANALYSIS 

04  MATERIAL  PROCUREMENT 

05  SCHEDULING 

06  ACQUISITION  PLANNING/STRATEGY 


07  ILS 


01  LIFE  CYCLE  COST 

02  ACQUISITION  COST 

0201  UNIT  COST 

0202  TOTAL  PROGRAM  COST 

03  OPERATING  &  SUPPORT  COST 

0301  UNIT  COST 

0302  TOTAL  COST 

04  ENERGY 

05  INFLATION 

01  SHIPYARD  WORKLOAD 
0101  NAVAL 
0102  COMMERCIAL 

02  SHIPYARD  CAPACITY/CAPABILITY 
01  GFE/GFI 

02  LLT  MATERIAL  PROCUREMENT 
03  CLAIMS  AVOIDANCE 
04  ADVANCE  PROCUREMENT 
05  SPD'S 

01  PROGRAM  SCHEDULE 

01  SHIPYARD  ALLOCATIONS 
02  CONTRACT  TYPES 
03  CLAIMS  AVOIDANCE 
04  COMPETITION 
05  RISK  MANAGEMENT 
06  DRAWING  VALIDATION 
07  FEASIBILITY  STUDIES 
08  CONCEPT  STUDIES 
09  LAND-BASED  TEST  SITE(S) 

10  SCHEDULE 

11  ILS 

12  T&E 

13  RM&A 

14  SHIPBOARD  MANNING/TRAINING 

15  MASTER  SCHEDULE  NETWORK 

16  COMBAT  SYS.  MGMT .  PLAN 

17  HUMAN  FACTORS 

18  PROGRESS/APPRAISAL 

19  SHIP  TRANSFER 

01  MAINTENANCE  PHILOSOPHY 

02  MANPOWER/TRAINING  PHILOSOPHY 

03  TECHNICAL  DOCUMENTATION 

04  MATERIAL  SUPPORT 

0401  BACKUP  SPARES 

0402  ONBOARD  REPAIR  PARTS 

0403  ROTABLE  POOLING 


Figure  1 
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08  RM&A 

09  T&E 

10  ASU 

11  QUALITY  ASSURANCE 

12  EXOGENOUS  INFLUENCES 


13  FINANCIAL  MANAGEMENT 

14  POLICY  CONFORMANCE  REVIEW 

15  ENGINEERING  DESIGN 


16  CONGRESSIONAL  LIAISON 

17  INFORMATION  MANAGEMENT 

18  PROJECT  MANAGEMENT 

19  CONTRACT  ADMINISTRATION 


01  NEW  EQUIPMENTS 
02  READINESS 
03  REDUNDANCY 
04  RISK  EVALUATION 
05  DESIGN  REVIEWS 

01  DEVELOPMENT  T&E 
02  OPERATIONAL  T&E 
03  PRODUCTION  ACCEPTANCE  T&E 
04  GROOMING 

01  OPEVAL 


01  CONGRESS 
02  OSD 
03  OMB 
04  GAO 
05  SECNAV 
06  OPNAV 
07  ENERGY 
08  ECONOMY 

09  REQUIREMENTS  CHANGES 

01  BUDGETING 
02  ACCOUNTING 
03  COST  CONTROL 


01  CONCEPT  FORMULATION 
02  CONCEPT  DESIGN 
03  PRELIMINARY  DESIGN 
04  CONTRACT  DESIGN 
05  DETAIL  DESIGN 
06  PRODUCEABILITY 


01  PROGRAMMATIC 
02  TECHNICAL 

01  CLAIMS  AVOIDANCE 
02  CONTRACTOR  PERFORMANCE 
03  CONTRACT  TYPES 
04  SOURCE  SELECTION 


Figure  1  cont'd 
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CONFIGURATION  MANAGEMENT 

01 

TRACEABILITY 

02 

CHANGE  MANAGEMENT 

03 

DRAWING  REVISIONS 

04 

CLAIMS  AVOIDANCE 

21  STANDARDIZATION 

22  SAFETY 

23  SECURITY 

24  ENVIRONMENTAL  IMPACT  ASSESSMENT 


(Figure  1  cont'd) 
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2 .  INTERVIEW  FINDINGS 
2,1  General  Findings 

As  the  project  team  progressed  through  the  interviews,  a  number  of 
common  ideas  and  attitudes  emerged,  revealing  a  remarkably  strong 
consensus  on  certain  issues. 

An  early  finding  was  the  realization  by  the  project  team  that  even 
in  the  case  of  someone  who  has  spent  most  or  all  of  his  professional 
career  in  ship  acquisition,  any  one  person  is  able  to  offer  at  best 
a  limited  perspective  on  the  ship  acquisition  process  with  all  its 
breadth  and  depth.  That  is  to  say,  human  beings  simply  do  not  live 
long  enough  and  are  too  professionally  mobile  to  have  experienced  all 
aspects  of  several  acquisitions  from  all  vantage  points.  The  conse¬ 
quence  of  this  is  that  the  project  team  has  had  to  do  considerable 
correlation  to  tie  these  limited  perspectives  together  into  a 
cohesive  fabric. 

Another  major  finding  is  that  in  the  acquisition  community,  as  else¬ 
where,  there  is  a  general  lack  of  appreciation  that  information,  like 
people,  money,  and  facilities,  is  a  resource  to  be  systematically 
managed.  The  interview  questions  about  information  required  for 
decision-making  and  other  functions  generally  elicited  no  meaningful 
response.  It  is  quite  clear  that  today's  acquisition  managers  have 
generally  not  been  educated  in  the  principles  of  information  manage¬ 
ment. 

Another  attitide  commonly  encountered  was  the  reluctance  of  well- 
established  acquisition  organizations  to  welcome  any  changes  to 
the  way  information  is  currently  handled,  such  changes  being  seen 
as  disruptive  to  existing  practice.  On  the  other  hand,  newly 
established  organizations  seem  to  have  an  unusually  open  mind  about 
improved  ways  of  managing  information.  This  attitude  difference 
is  definitely  relevant  to  choosing  target  implementation  organiza¬ 
tions  later  on,  for  information  tools  developed  during  the  course 
of  this  project. 
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There  was  widespread  agreement  among  the  interviewees  that  the 
decisions  made  in  the  early  stages  of  an  acquisition  (prior  to 
DSARC  Milestone  I)  are  generally  the  most  significant  decisions 
made  during  the  lifetime  of  an  acquisition  in  terms  of  impact. 

2.2  Findings  Related  to  Interviewee's  Environment 


The  interviews  revealed  an  attitude  which  seems  to  be  strongly  and 
universally  held,  that  being  the  attitude  that,  "I  am  competent  to 
do  the  job  to  which  I  am  assigned",  and  "I  neither  desire  nor  ap¬ 
preciate  the  meddling  of  those  who  are  looking  over  my  shoulder". 
Another  way  the  same  attitude  is  expressed  is,  "I  really  don't  want 
'help'  from  all  those  who  say  they  are  trying  to  help  me  do  my  job". 
The  underlying  fear  is  one  of  giving  up  control  of  one's  influence 
over  events  to  the  party  seen  as  the  meddler.  This  attitude  is  not 
generally  held  toward  other  persons  in  one's  immediate  office,  but 
rather  relates  to  persons  from  other  codes  in  the  command  or  other 
commands . 

There  are  two  primary  reasons  for  mentioning  this  pervasive  atti¬ 
tude.  One  is  that  it  is  so  widespread,  and  the  other  is  that  it 
results  in  people  having  a  very  possessive  (and  often  selfish) 
attitude  about  the  information  under  their  control.  This,  of 
course,  must  greatly  affect  the  design  of  any  information  tools 
which  can  facilitate  sharing  of  information.  The  fact  that  these 
tools  can  facilitate  sharing  offers  no  assurance  that  they  will  be 
used  to  facilitate  sharing  of  information.  The  best  way  to  inhibit 
the  impact  of  someone  seen  as  meddling  in  one's  business  is  to 
"stonewall"  the  meddler's  requests  for  information. 

This  is  clearly  a  problem  in  organizational  behavior  which  presents 
both  challenges  and  opportunities.  Perhaps  the  availability  of  more 
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consistent,  complete,  timely  and  accurate  information  will  gradually 
erode  some  of  the  barriers  to  sharing  of  information  which  people 
have  erected  to  prevent  embarrassing  or  confusing  situations  caused 

by  the  use  of  information  which  is  incomplete,  inaccurate,  inconsistent 
or  untimely. 

On  the  other  hand,  it  seems  to  be  generally  recognized  that  the 
"bureaucratic  meddling"  which  goes  on  is  simply  an  intrinsic  feature 

of  a  peacetime  bureaucracy  which  places  great  emphasis  on  risk 
avoidance. 

Several  of  the  interviewees  expressed  for  both  their  immediate  or¬ 
ganization  as  well  as  their  command,  a  desire  for  greater  profession¬ 
al  respect.  This  may  well  be  the  opposite  side  of  the  "meddling/ 

monitoring"  coin;  greater  professional  respect  would  tend  to  reduce 
meddling  by  outsiders. 

Last,  the  opinion  was  expressed  by  all  the  interviewees  with  project 
management  experience,  that  to  know  in  considerable  detail  the  cor¬ 
porate  condition  of  their  shipbuilding  contractors  was  essential. 

— Findings  related  to  interviewees  current  function 

The  discussions  with  upper-level  interviewees  regarding  their 
decision-making  activities  were  interesting.  All  saw  their  decision¬ 
making  as  unstructured  and  largely  reactive  to  external  stimuli. 
Additional  interviews  of  lower  level  people  will  probably  show  that 

the  degree  of  structure  of  decision-making  is  inversely  proportional 
to  position  level. 

2.4  Findings  related  to  concerns  and  goals 

After  the  first  few  interviews  were  conducted,  it  became  evident 
that  the  majority  of  concerns  and  goals  fell  into  less  than  ten 
categories.  After  these  categories  were  identified,  an  interview 
question  (Attachment  #4,  last  question)  was  developed  asking  the 
respondent  to  rank  each  category  from  1  to  5,  indicating  whether 
improved  information  in  that  category  was  very  valuable  (5)  to 
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not  of  value  (1)  to  him. 


The  average  ranking  given  each  category  is  shown  in  Figure  2. 
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FUNCTION  Value  of  Having  Better 

Information  in  This  Area 
Ranking  From  1  (not  of  value) 
to  5  (very  valuable) . 


Acquisition  Planning 

Systematic  Project  Histories 
Change  Management 
Impact  Analysis 

Cost  Estimating 


GFE/GFI  Management  4  • 1 
Project  Financial  Management  4-2 
Preparing  Varicus  Froject  Management  Plans  3.0 


Project  Problem  Management  3.0 
Contract  Administration  2.5 
Personnel  Administration  2.0 


Figure  2 
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Since  the  aforementioned  functions  have  been  described  only  in 
terms  of  two  or  three  words,  it  is  appropriate  at  this  juncture 
to  elaborate  on  what  is  meant  by  these  functional  titles. 

2.4.1  Acquisition  Planning 

An  acquisition  basically  involves  creating  Program  Plans  and 
Technical  Plans  and  then  attempting  to  execute  those  plans.  Program 
plans  include  a  Ship  Acquisition  Plan,  a  Test  and  Evaluation  Master 
Plan,  an  Operational  Requirement,  Ship  Project  Directives  and  other 
such  management  documents.  Technical  plans  include  ship  design 
products  such  as  drawings,  specifications,  and  bills  of  material. 

The  technical  plans  are  supposed  to  evolve  through  a  series  of  states 
referred  to  as  baselines;  for  example,  Conceptual  Baselines,  or 
Functional  Baselines. 

Owing  to  a  number  of  factors,  it  becomes  desirable  and/or  necessary 
to  frequently  effect  changes  to  those  plans.  Program  plans  also 
undergo  change,  with  specific  revision  efforts  occurring  largely  at 
significant  project  review  points. 

The  systematic,  disciplined  management  of  this  change  activity  is 
what  is  meant  by  the  term.  Change  Management . 

This  area,  which  received  the  highest  ranking  as  noted  in  Figure 
3-1,  poses  a  tremendous  challenge,  as  well  as  very  substantial  op¬ 
portunity  to  impart  greater  efficiency  and  efficacy  to  the  ship 
acquisition  process.  A  skeletal  concept  for  attacking  this  area 
is  presented  in  Figure  3.  Considerably  more  work  is  required  to 
fully  develop  a  methodology  for  change  management. 

The  high  ranking  given  to  Systematic  Project  Histories  was  motivated 
by  the  interviewees 1  desires  to  have  a  systematically  organized 
"corporate  memory",  which  is  regularly  refreshed  with  recent  history 
and  which  can  be  a  major  source  of  insight  for  contemporary  acqui¬ 
sition  managers  planning  future  acquisition  activity.  Concern  was 
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CHANGE  MANAGEMENT 


I.  BACKGROUND 

1)  Change  is  inevitable;  will  it  be  actively  managed  or 
passively  allowed  to  occur? 

2)  There  are  technical  changes  and  programmatic  changes. 

3)  Technical  change  equals  baseline  modification. 

4)  Authority  to  make  and  report  changes  must  be  clearly 
defined . 

5)  Data  integrity  must  be  respected  or  data  sources  will 
not  be  maintained. 

II.  PROBLEM 

1)  Ship  definition,  design,  and  construction  is  an  extremely 
complex  interaction  of  requirements  versus  constraints, 
involving  many  people  over  lengthy  periods  of  time. 

2)  The  responsibilities  and  motiviations  of  these  people 
change  during  the  process. 

3)  Communications  among  these  people  are  significantly  less 
than  100%  effective. 

4)  Technology  changes  with  time. 

5)  Leadership  changes  with  time. 

III.  OBJECTIVE 


Define  a  methodology  which  provides: 

1)  Translation  of  requirements  to  mission  systems. 

2)  Mission  systems  to  hardware  systems. 

3)  Hardware  systems  to  ship  integration. 

4)  Feedback  and  recording  of  change. 

5)  Manage  change  from  beginning  of  concept  definition  to 
final  turnover  of  last  ship. 

IV .  CHANGE  MANAGEMENT  METHODOLOGY 

1)  Describe  top  level  requirement  and  ship  mission  statements 


Figure  3 
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in  discrete  ship  system  hardware  "packages".  Packages 
must  be  stand-alone  and  must  describe  system  integration 
interfaces . 

2)  These  ship  system  hardware  "packages"  are  organized  in  an 
equipment,  sub-system,  system  hierarchy. 

3)  Ship  cost,  weight,  size,  endurance,  constraints,  etc., 
are  defined  in  terms  of  the  discreet  ship  system  packages. 

4)  Maintain/update  ship  system  "packages"  as  ship  definition, 
design,  and  construction  progresses. 


Figure  3  cont'd. 
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expressed  that  lacking  a  systematically  maintained  corporate  memory, 
lessons  learned  are  lost  and  different  projects  work  from  different 
fact  bases,  creating  an  image  for  the  Navy  of  inconsistency  and  un¬ 
reliability. 

Impact  Analysis  is  the  terra  given  to  the  function  which  largely 
involves  answering,  "what  if?"  type  questions.  It  is  the  element  of 
acquisition  planning  which  investigates  potential  program  or  tech¬ 
nical  changes  in  the  earlier  stages  of  their  consideration. 

The  three  elements  of  acquisition  planning,  namely  Impact  Analysis, 
Change  Management,  and  Systematic  Project  Histories,  are  essentially 
the  head,  body,  and  tail,  respectively,  of  acquisition  planning. 

Impact  Analysis  has  to  do  with  potential  changes,  Change  Management 
deals  with  managing  all  the  detailed  implications  of  any  particular 
program  or  technical  change,  and  Systematic  Project  Histories  involve 
laying  down  an  accurate  track  of  what  actually  happened. 

The  initial  round  of  interviews  clearly  points  to  Acquisition  Planning 
as  the  area  of  highest  interest. 

2.4.2  Cost  Estimating 


The  apparent  reason  for  which  the  interviewees  gave  cost  estimating 
a  high  ranking  was  a  desire  to  more  systematically  maintain  an  easily 
accessed  track  of  individual  cost  estimates  with  their  attendant 
assumptions.  Further  investigation  is  required  to  confirm  if,  in¬ 
deed,  this  is  the  reason  for  interest  in  this  function.  If  it  is, 
this  function  can  be  included  as  part  of  the  methodology  developed 
for  maintaining  Systematic  Project  Histories. 

2.4.3  GFE/GFI  Management 

This  term  refers  mainly  to  maintaining  an  accurate  status  of  GFE  and 
GFI  in  each  acquisition  project  so  the  government  can  minimize 
project  disruption  due  to  late,  incomplete,  inaccurate  or  damaged 
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GFE/GFI .  This  is  an  area  which  is  seemingly  mundane,  but  one  where 
acquisition  managers  express  a  desire  to  improve  the  Navy's  perfor¬ 
mance  . 

2.4.4  Project  Financial  Management 

The  emphasis  given  this  function  appears  to  derive  from  a  recogni¬ 
tion  that  one  of  the  essential  classical  elements  of  management  is 
maintaining  accurate  budgets,  journals  and  ledgers  and  preparing 
financial  reports.  If  there  is  a  problem  in  this  area,  it  is  that 
there  is  a  tendency  for  each  acquisition  to  invent  (at  considerable 
cost)  its  own  unique  system  for  financial  management.  This  is  a 
function  with  sufficient  generality  to  strongly  suggest  the  feasi¬ 
bility  of  developing  one  or  more  standard  information  tools  to 
support  financial  management. 

2.4.5  Preparing  and  Disseminating  Various  Management  Plans 

The  interviewees  expressed  a  concern  about  the  amount  of  labor 
expended  to  prepare,  revise,  review  and  distribute  the  many  program¬ 
matic  documents  involved  in  ship  acquisition.  This  was  frequently 
mentioned  as  an  area  significantly  contributing  to  expensive  costs 
and  delays  in  the  acquisition  process . 

It  is  quite  clear  that  the  largely  manual  methods  currently  in  use 
in  this  function  are  costly  and  inefficient.  The  use  of  more 
contemporary  information  management  methods  would  significantly 
enhance  this  function  by  relying  much  more  heavily  on  processing 
this  information  by  electronic  vice  manual  means  . 

Given  that  preparing,  revising  and  distributing  the  various  program 
management  plans  is  part  of  the  acquisition  planning  function,  and 
particularly  the  change  management  function,  there  is  a  logical 
basis  for  including  the  function  discussed  in  this  section  under 
the  broader  area  of  acquisition  planning. 
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2.4.6  Project  Problem  Management 

There  is  general  recognition  that  the  typical  acquisition  mangers 
spends  a  substantial  portion  of  his  time  managing  the  current  list 
of  problems.  These  problems  can  be  technical  or  programmatic,  but 
most  always  involve: 

(1)  Defining  the  problem  from  available  data  sources 

(2)  Correlating  the  problem  with  other  related  problems 
or  occurrences 

(3)  Analyzing  the  problem 

(4)  Generating  a  corrective  action 

(5)  Implementing  the  corrective  action 

(6)  Verifying  that  the  problem  is  solved 

Given  that  at  any  time,  an  acquisition  project  frequently  has  hun¬ 
dreds  of  problems  in  various  of  the  above  stages,  and  frequently 
tasks  numerous  outside  organizations  to  accomplish  problem  analysis, 
corrective  action,  etc.,  it  is  clear  that  a  systematic  information 
management  discipline  is  required  to  stay  on  top  of  it  all.  Lack¬ 
ing  any  discipline  of  this  sort,  past  acquisition  projects  have 
devolved  into  a  reactive  mode,  having  "lost  the  bubble"  on  who  is 
doing  what  and  when. 

Recent  successes  with  ADCAP  (Acquisition  Deficiency  Corrective  Action 
Program)  have  demonstrated  the  potential  efficiencies  which  can 
be  imparted  to  the  acquisition  process  with  a  more  disciplined 
approach  to  problem  management. 

2.4.7  Contract  Administration  and  Personnel  Administration 

These  two  functions  will  be  discussed  together  because  they  have 
many  qualities  in  common  in  the  eyes  of  the  interviewees. 

It  was  nearly  a  universal  consensus  that  Contract  Administration 
and  Personnel  Administration  are  functions  which  contribute  greatly 
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to  dealys  and  increased  costs  in  the  acquisition  process.  Acquisi¬ 
tion  managers  tend  to  view  these  functions  as  "black  boxes"  called 
NAVSEA  002  and  02,  with  whom  they  have  to  interact  to  accomplish 
anything  regarding  personnel  or  contracts. 

Comments  about  what  to  do  about  this  problem,  however,  varied  from 
"leave  it  alone,  the  problem  is  bigger  than  all  of  us",  to,  "let's 
keep  track  of  their  record,  so  we  can  embarrass  them  into  a  better 
performance",  to,  "let's  get  into  those  black  boxes  to  see  what  can 
be  done  to  improve  things". 
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3.  NAVMAT/NAVSEA  EXISTING  SHIP  ACQUISITION  DECISION  PROCESS 
MODELS  AND  ALGORITHMS 


Within  the  Naval  Material  Command  and  the  Naval  Sea  Systems  Command 
there  are  numerous  data  bases  supporting  various  acquisition  manage¬ 
ment  functions.  Of  the  40  Management  Information  Systems  listed  in 
NAVSEA  NOTE  5230  of  11  April  1980,  which  are  related  to  the  acquisi¬ 
tion  process,  about  75%  support  ship  acquisition  decision-making  to 
some  degree.  There  are  in  addition  a  number  of  management  informa¬ 
tion  systems  operated  and  maintained  by  NAVMAT  or  NAVSEA  contractors 
which  support  the  acquisition  management  process. 

Nearly  all  of  the  data  bases/management  information  systems  noted 
herein  are  simply  computerized  filing  systems  and  do  not  embody  any 
significant  degree  of  decision-making  methodology.  That  is  to  say, 
use  of  ADP  processes  within  the  acquisition  community  is  limited 
primarily  to  maintenance  of  reference  files  required  in  support  of 
acquisition  management.  Only  one  system  stands  out  as  an  integral 
part  of  a  systematic  formal  decision  methodology,  namely  the  P3BS . 

Most  decision-making  algorithms  can  be  considered  to  be  non-autoraated, 
formal  only  to  the  extent  they  are  in  accord  with  broad  policy 
directives,  and  supported  by  numerous  manual  and  computer-based 
reference  files.  Since  these  algorithms  are  required  in  most  cases 
to  be  in  accord  only  with  fairly  general  policy  guidelines,  the 
algorithms  themselves  change  as  different  people  rotate  in  and  out 
of  various  acquisition  management  positions. 

3,1  Following  is  a  Partial  Listing  of  Data  Bases 

Model/Algorithm  Sponsor  or  Customer 

Defense  Major  System  Acquisitions  DOD 

(A-109,  DSARC ,  etc.) 

PPBS  (POM,  FYDP ,  etc.,)  Navy  Department 

AEGIS  MIS  (PCS)  PMS  400 

Provides  for  detailed  planning  of  AEGIS 
Program 

(IBM  370/168  at  NIH) 
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Mode 1/Algor ithm  Sponsor  or  Customer 

HEL  Management  &  Technical  Data  System  PM-22/PMS  405 
Program  Control,  contract  status, 
and  Technical  Data  Files 
(UNIVAC  1108,  FAC,  Corona,  Cal) 

PMS  303  ( PHM/MCM)  MIS  PMS  303 

Operational  and  Technical  Data  for 
program  and  contract  control 
( CDC  6700  &  600  at  DTNSRDC) 

PMS  383  Logistics  Data  Management  System  PMS  383 
Management  Tool  for  planning  and 
controlling  ship  acquisition  programs 
(CDC  6600/6700  at  DTNSRDC) 

Coordinated  Ships  Data  Systems  SEA  071 

Planning,  monitoring  and  reporting 
the  production  phases  of  the  Navy 
shipbuilding  and  conversion  program 
(UNIVAC  1108,  CSC  INFONET,  Los  Angeles, 

Cal) 

Long  Range  Planning  System  SEA  071 

Projects  long  range  ship  schedules, 
manpower,  drydock,  berthing  require¬ 
ments;  reports  for  POM/FYDP 
(IBM  370/168,  USDA  WASH,  DC;  CDC  6700 
etc.,  DTNSRDC) 

Weapons  System  Acquisition  Review  CNM 

Selected  Acquisition  Tracking  System  MAT  09H 


Ship  Acquisition  Plan  Outline  and  Ship 
Acquisition  Plan 


COMNAVSEA 
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Model/Algorithm 

Combat  System  MIS 

Generate  schedules,  provides  for 
updating  and  distribution  of  sche¬ 
dules  and  configuration  matrices. 

(CDC  6500  at  NSWC,  White  Oak) 

PHALANX  Ship  Installation  Plan 

Integrates  ship  availability  with 

PHALANX  production 

(CDC  CYBER- 7 3  at  UNA,  McLean, VA) 

Combat  Systems  Master  Plan 

Ship  Portable  Electrical/Electronics 
Test  Equipment  Requirement  List  (SPETERL) 
Establish  requirements  for  SPETERL. 

Plan  and  program  to  meet  requirements. 
(Honeywell  H2060  at  SEAADSO) 

Ships  Support  Improvement  Project- 
Logistics  Data  System  (FFG-7) 

Processes  LSA  data  for  support 
Managers 

(IBM  360  at  SPCC  managed  by  NAMSO) 

Integrated  Logistics  Support  Plan 

RM&A  Program  for  Design, Development 
and  Acquisition 

Logistic  Support  Plan 

(FFG-7  Data  Base  contractor  main¬ 
tained) 

(Sperry  SSM) 


Sponsor  or  Customer 

SEA  06D 

SEA  62YD 

COMNAVSEA 

SEA 06 C/MAT  04T 

PMS  306/399 

SEA  04L1 

SEA  902 


CSM/COMNAVSEA 
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Model/ Algorithm 

Sponsor  or  Customer 

Material  Planning  &  Programming  System 
for  Shipbuilding  and  Conversion  (Navy) 
Establishes  Master  Equipment  Lists, 

SEA  05M 

tracks  GFE/GFI ;  produces  budgets  and 

financial  reports;  supports  POM. 

Contractor  maintained 

(CDC  6700  at  DTNSRDC) 

New  Construction  Analysis 

Identifies  and  tracks  material 

SEA  63FM 

requirements . 

(IBM  360/370  at  NIH) 

Phased  Outfitting  Provisioning  System 
Management  of  Phased  Outfitting  and 
Provisioning  Programs  for  new  equip¬ 

SEA  041 

ment  . 

(UNIVAC  494  at  SPCC) 

Procurement  Action  Status  Report 

Monitor  all  procurement  requests; 

remote  update  and  inquiry. 

(IBM  370/165  at  NARDAC ,  Arlington,  VA) 

SEA  0212 

Procurement  Report  Control 

Provides  statistical  data  on 

SEA  02 

Contracts/Mods  for  procurement 

(IBM  370/165  at  NARDAC,  Arlington,  VA) 

Total  Ship  Test  Program  for  Ship  Production  06C2/05L2 


Test  and  Evaluation  Master  Plan 

COMNAVSEA 

Test  Documentation  Index  File 

SEA  93M 

Manage  development  of  Test  Programs 
and  Procedures.  Report  status  and 
problems  in  testing. 

(UNIVAC  1108  CSC-INFONET ,  Beltsville,  MD) 
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Model/Algorithm 

Test  and  Evaluation  (Schedule, 
Monitoring;  Many  contractor 

maintained  management  information 
systems) 

Navy  Training  Plans 

Provide  MP&T  Planners  with  advance 
planning  information. 

(IBM  370/165  NARDAC  Arlington,  VA) 

Service  Approval  Status  List 

Updated  approval  list  for  all  NAVSEA 
projects . 

(NMCSA  IBM  1401) 

Fitting  Out  Management  Information 
System  (FOMIS) 

Monitor  and  display  GFE/CFE. 

Provides  baseline  for  SECAS. 

(U  494  SPCC) 

COSAL  Requisitioning  and  Status 
Procedure 

Provide  support  in  ordering, 
monitoring  and  tracking  of  out¬ 
fitting  material. 

(BURROUGHS  T3-3500,  OUTFIT  SUPPLY 
ACTIVITIES  AT  NSCOAK,  NORVA,  CHASN) 

Acquisition  Deficiency  Corrective 
Action  Program 

Creates,  maintains  and  summarizes 
listings  of  the  INSURV  Master  File. 
Manages  resolution  of  discrepancies. 
Contractor  - 
(ROH,  Inc)  Maintained 
(GE  Maintenance,  DEC  Terminals) 


Sponsor  or  Customer 

Various 

SEA  05L1C 

4 

SEA  902/OPNAV  411 

SEA  041 

SEA  04122 


PMS  399 
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Model/Algorithm 

Sponsor  or  Customer 

Deficiency  Item  Management  System 

SEA  074/SUPSHIP ,  Newport  News 

Support  SUPSHIP,  Newport  News  in 
managing  resolution  of  INSURV 
discrepancies . 

(UNIVAC  AC  1108  CSC-INFONET) 

CVN-68  Class  Status  of  INSUEV 

Discrepancies 

PMS  392 

Support  PMS  392  in  managing  resolu¬ 
tion  of  INSURV  discrepancies. 

(CDC  6700  at  DTNSRDC) 

Consolidated  Change  Reporting  System 

PMS  392 

Records  basic  data  on  changes  from 
inception  of  ECP  to  adjudication  of 

contract  modification. 

(HONEYWELL  440-GSA,  Atlanta) 

Automated  Data  Base  on  GFE  for 

Configuration  Management. 

Contractor  Maintained  (SPERRY  SSM) 

PMS  399 

HMR/ECP  Data  Base 

PMS  399 

Contractor  Maintained  (VITRO) 

Record  of  Changes  (ROC) /SCN 

SEA  90R 

Semi-automated  MIS  for  SCN 

contract  changes. 

(NMCSA  -  IBM  360/65) 

Configuration  Control  Board  Operations 
for  Systems  and  Equipments 


SEA  62T1 
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Model/Alqorithm  Sponsor  or  Customer 

Logistic  Data  Improvement  Program 

Management  Information  Data  Base  SEA  05L3 

Report  Technical  Manual  Deficient 
(IBM  360  Model  91,  APL) 

Ships  Technical  Data  MIS/Ships  Technical  SEA  05L/OP401 
Publication  System  (STEDMIS/STEPS) 

Prime  data  system  for  information 
about  technical  publications  for 
use  in  ships. 

(STEDMIS  IBM  360/0S,  NSDSA  &  PDP  -11/70, 

Port  Hueneme) 


NAVSEA  Active  Contract  Report  and 
Completed  Contract  Report 

Information  on  contracts  and  Mods 
from  date  of  issuance  until  closed 
out  by  purchasing  office. 

(IBM  360/370  at  NARDAC ,  Arlington,  VA) 


SEA  0212 


Procurement  Accounting  and  Reporting 
System  (PARS) 

Provide  financial  information  to 
enable  management  to  execute  and 
control  programs. 

(IBM  360/65,  IBM  270/165) 

Cost  Estimating  Data  Base 

Provides  6  cost  estimating  data 
bases  to  assist  SHAPMs. 

UNIVAC  1108  CSC-INFONET ) 


SEA  01P2 


SEA  017 


Pace  E-25 


Models/Algorithm 


Sponsor  or  Customer 


Program  Review  System 

Cost  estimating  and  financial  review 
system  for  the  SCN  appropriation 
(IBM  370,  NARDAC ,  Arlington,  VA) 


SEA  010 


Navy  Cost  Information  System 


SEA  0102 


PPBS  system  providing  data  for 
Navy  FYDP 

(IBM  370/165,  NARDAC,  Arlingotn,  VA) 

NAVSEA  Unified  Vendor  Evaluation/ 

Unsatisfactory  Material  Reporting 

(NUVEP/UMR)  Vendor  Performance  SEA  90 

System 

Provides  information  for  management 
in  material  procurement  decision¬ 
making  process. 

(HONEYWELL  H  6060  at  PNSY,  Ports.,  NH) 

Research  and  Development  MIS  SEA  003 

Tasks  financial  and  technical 
information  on  NAVSEA  R&D  Projects. 

Develops  RDT  &  EN  budget. 

(IBM  360  at  NMCSA,  Arlington,  VA) 

Foreign  Military  Sales  MIS 

Planning  and  Financial  tracking 
and  reporting 
(IBM  370/168  Dallas,  TX) 

(Datapoint  2200  San  Diego,  CA) 


SEA  0184 
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3.2  Following  is  a  listing  of  these  data  systems  catagorized  by 
major  functional  area  with  notation  as  to  who  are  the  primary 
users,  to  indicate  where  the  same  information  is  flowing  into 
different  organizations. 

o  Ship  Acquisition  Planning 

Long  Range  Planning  System  (SEA  071) 

Customers:  SEA  071/070,  OP  43,  NSY ,  SOS  &  SLD's. 

Ship  Acquisition  Plan  Outline/Ship  Acquisition  Plan 
Customers:  SEA  00,  SEA  90,  SEA  92/93  or  94. 

Coordinated  Ship  Data  System  (SEA  071) 

Customer:  SEA  00,  OSD,  OMB,  MARAD,  CONGRESS. 

o  Integrated  Logistics  Support 

Integrated  Logistics  Support  Plan  (SEA  04L1) 

Customers:  SHAPM,  SLD,  SEA  04  Codes. 

Logistics  Support  Plan  (FFG-7) 

Customers:  PMS  399,  SEA  04  Codes,  SEA  931 

Ship  Support  Improvement  Program  -  Logistics  Data  System  (FFG-7) 
Customers:  PMS  306/399,  SEA  04  Codes/SEA  931,  NAVSEA  MECH  DET, 

NSWSES ,  NAVELEX,  SPCC,  PERA (CRUDES) . 

PMS  383  Logistics  Data  Management  Information  System  (SEA  05L3) 
Customers:  PMS  383,  SEA  05L1C,  SUPSHIPS  NOrleans,  SDiego, 

Seattle,  NSWSES,  NAVSEACENPAC/LANT,  Support  Contractor 
Automated  Data  Base  on  GFE  (PMS  399) 

Customers:  PMS  399 

Material  Planning  and  Programming  for  SCN  (SEA  05M) 

Customers:  SHAPM1 s,  PARM's 

New  Construction  Analysis  (SEA  63  FM) 

Customer:  SEA  63FM 

-  Fitting  Out  MIS  (SEA  041) 

Customers:  SHAPM,  NSY,  SOS,  ICP,  PTD  Review  Activity. 
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Phased  Outfitting  and  Provisioning  System  (SEA  041) 
Customers:  Acquisition  Project  Manager,  SPCC,  Contracting 

Officer,  PESA. 

COSAL  Requisitioning  and  Status  Procedures  (SEA  04122) 
Customers:  Navy  Supervisory  Activities,  Outfit  Support  Acti-- 

ity,  Fitting  out  Activity,  Naval  Shipyard,  Ships 
Ships  Portable  Electrical/Electronics  Test  Equipment  Require¬ 
ments  List  (SEA  06C) 

Customers:  Procurement  Activities,  Shipyards,  SOS,  TYCOMS , 

Ships  SOAP  Teams. 


o  Combat  Systems 

Combat  Systems  MIS  (SEA  06D) 

Customers:  NAVSEA,  NWC,  NSWC,  NSWSES ,  NAVELEX,  OP03/04 

Combat  Systems  Master  Plan 

Customer:  NAVSEA,  NWC,  NSWC,  NSWSES,  NAVELEX,  OP03/04 

Phalanx  Ship  Installation  Plan  (SEA  62YD) 

Customers:  PMS  404,  SEA  05L1,  OP35/43,  SEA  01 

o  Equipment/Material  Qualification 

-  NUVEPS/HMR  (SEA  90) 

Customers:  DCAS NAVORDSTAS,  NAVPROS ,  NAVSEA,  NSYs,  NUSW  Eng  Sta, 

NAVSSES ,  NSTRS ,  PERA(SS),  SDCC,  SUPSHIPS,  NWS 
Approval  for  Service  Use  (SEA  902) 

Customers:  SHAPMs,  Systems  Designers,  OPNAV  Field  Activities 

RM&A  Programs  (SEA  902) 

Customer:  SEA  902 

Selected  Acquisition  Tracking  System  (MAT  09H) 

Customers:  SHAPMs,  NAVMAT 
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o  Testing  Programs  and  Procedures 


-  TSTP/SP 

Customers:  SEA  93,  PERA ( CRUDES ) ,  NSYs,  SOS,  TYCOM,  SHIPSFORCE 

-  TEMP 

Customers:  SEA  93,  PERA (CRUDES )  NSYs,  SOS,  TYCOM,  SHIPSFORCE 

-  T&E 

Customers:  SEA  93,  PERA (CRUDES ) ,  TYCOM,  SHIPSFORCE 

Test  Documentations  Index  File  (SEA  93M) 

Customers:  SEA  93,  PERA (CRUDES ) ,  NSYs,  SOS,  TYCOM,  SHIPSFORCE 

o  Acquisition  Deficiency  Correction 

-  ADCAP  (PMS  399,  PMS  383,  SEA  93 X) 

Customers:  PMS  399,  SUPSHIPS,  SEA  90,  93,  TYCOM,  PMS  383, 

SEA  93X,  SEA  03 

-  DIMS  (SEA  074) 

Customer:  SEA  074,  SUPSHIPS  Newport  News,  SUPSHIPS 

CVN  68  Class  INSURV  Deficiency  Support  (PMS  392) 

Customer:  PMS  392,  SUPSHIP ,  SEA  94,  TYCOM 


o  Change  Control 

-  ROC/SCN  (SEA  90R) 

Customers:  SEA  90,  SUPSHIPS,  SHAPMs ,  NAVSEA  CONTRACTS 

DIRECTORATE 

-  Consolidated  Change  Reporting  System  (PMS  392) 

Customers:  PMS  392,  SUPSHIPS  Newport  News,  TYCOM 

-  HMR/ECP  Data  Bases 

Customers:  SHAPMs,  SUPSHIPS,  TYCOM 

-  Change  Control  Board  Operations 

Customers:  SHAPMs,  SUPSHIPS,  TYCOM 
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o  Technical  Documentation 


STEDMIS/STEPS  (SEA  05L) 

Customers:  Fleet,  PERA,  SEA  05L,  NSDSA,  SHAPMs,  SLDs ,  PARMs , 

SUPSHIPS,  NSYDs ,  NETC,  NAVSEA  CODES 
Logistics  Data  Improvement  Program  MIDB  (SEA  05L3) 

Customers:  SEA  05L33 ,  NSDSA,  Cog  Engrs. 

o  Cost  Accounting  and  Estimating 

-  PARS  (SEA  01P2) 

Customers:  OPNAV,  NAVCOMPT ,  CNM ,  SYSCOMS ,  NRFC 

Cost  Estimating  Data  Base  (SEA  017) 

Customer:  SHAPMs 

Program  Review  System  (SEA  010) 

Customers:  SYSCOMS,  OPNAV,  DOD,  CNM 

Navy  Cost  Information  System  (SEA  0102) 

Customers:  SYSCOMS,  OPNAV,  DOD,  CNM 

o  Contract  Management 

NAVSEA  Active  Contract  Report  &  Completed  Contract  Report 
(SEA  0212) 

Customers:  HQ  and  Field  Support  Activities 

Procurement  Reporting  Control  (SEA  02) 

Customers:  NAVMAT/NAVSEA 

Procurement  Action  Status  Report  (SEA  0212) 

Customers:  NAVSEA  Procurement  Activities  and  Managers. 
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4.  DECISION  MODEL  AND  DATA  BASE  DEFICIENCIES 

Our  research  has  identified  five  significant  deficiencies  regarding 
decision  models  and  data  bases  in  the  acquisition  process. 

A  very  fundamental  deficiency  is  that  most  extant  decision  algorithms 
relevant  to  various  acquisition  management  functions  are  non-automa- 
ted,  generally  constrained  only  by  broad  policy  directives,  and 
therefore  subject  to  constant  change  as  personalities  change  within 
a  given  acquisition  function.  Only  the  PPBS  process  stands  out  as  a 
clear  exception  to  this  condition.  PPBS  demands  adherence  to  a 
clearly  defined  sequence  of  information  submission,  decision  and 
aggregation  procedures.  Second,  nearly  all  uses  of  data  processing 
techniques  within  acquisition  management  functions  focus  entirely  on 
maintenance  of  files  of  reference  data  rather  than  serving  as  an 
integral  part  of  a  systematic  decision-making  procedure,  as  discus¬ 
sed  earlier. 

A  third  area  of  deficiency  is  the  lack  of  automated  impact  analysis 
modules  having  access  to  various  reference  files  which  would  permit 
managers  to  answer  the  "what  if"  type  of  questions  regarding  impact 
on  their  program  of  alternative  changes  under  consideration.  The 
need  for  this  generic  category  of  information  tool  is  addressed  in 
the  main  body  of  our  report. 

Fourth,  a  widely  acknowledged  deficiency  is  the  failure  to  systema¬ 
tically  capture  and  record  for  posterity  the  significant  data  elements 
which  constitute  a  history  of  each  acquisition  project.  Again,  this 
is  addressed  in  the  main  body  of  our  report. 

Lastly,  since  the  existing  set  of  acquisition-related  data  processing 
applications  were  permitted  to  be  created  in  the  absence  of  any 
corporate  "concept  design"  for  information  management,  the  degree  of 
compatibility  and  integration  among  them  is  nil.  Most  of  the  exist¬ 
ing  data  bases  were  created  by  individual  SHAPMs,  or  by  individual 
functions  with  NAVSEA  02,  04,  05,  06,  and  07,  generally  without 
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regard  for  requirements  outside  the  immediate  code  creating  the 
system.  Further,  from  SHAPM  to  SHAPM  there  has  been  considerable 
"reinvention  of  the  wheel".  The  listing  of  existing  data  systems 
in  the  previous  section  includes  over  a  dozen  systems  within  various 
SHAPMs  considered  by  each  SHAPM  to  be  all  or  part  of  his  "SHAPM  MIS". 
The  same  phenomenon  exists  among  the  PARMs .  NAVSEA  is  spawning  a 
continually  growing  population  of  data  bases  designed  to  serve 
various  parochial  interests,  generally  being  designed  and  implemented 
without  regard  for  the  issues  of  compatibility  and  redundancy.  We 
are  not  suggesting  that  a  standard  SHAPM  MIS  could  be  designed  which 
meets  the  requirements  of  all  SHAPMs.  What  is  both  possible  and 
advisable,  is  to  constrain  these  developments  to  remain  within  a 
concept  design  established  on  a  command  basis  to  ensure  maximum 
compatibility  among  sub-systems.  We  detail  design  our  ships  within 
constraints  created  during  concept  design  and  apply  the  principles 
of  design  integration  to  ships.  Exactly  the  same  discipline  is 
urgently  needed  to  create  a  concept  design  for  a  system  to  manage 
NAVSEA' s  acquisition  information.  Then  compatible  sub-systems 
could  be  designed  and  implemented  to  support  the  various  sub-functions 
within  the  command.  These  various  information  management  tools, 
when  made  available  to  various  NAVSEA  offices,  would  serve  as 
building  blocks  for  their  individual,  uniquely  different  data  systems. 
This  would  preclude  some  of  the  unnecessary  redundant  development 
currently  existing. 

The  integration  and  compatibility  referred  to  here  is  a  necessary 
prerequisite  for  achieving  the  change  management  capability  referred 
to  in  the  main  body  of  the  report  which  will  facilitate  more 
systematic  follow-up  to  decisions  made  to  effect  changes  to  an 
acquisition  program. 
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INTERVIEW  QUESTIONS 

A.  Revelatory  Portion  of  Interview 

To  understand  the  acquisition  environment 

o  What  environmental  factors  are  critical  to  the  success 
of  your  function? 

o  What  significant  information  sets  do  you  generate  for 
use  outside  your  function? 

o  What  outside  information  sets  do  you  depend  on  to 
perform  your  function? 

To  understand  functions 
o  Would  you  summarize  your  function? 
o  Would  you  categorize  the  decisions  you  make? 
o  What  key  internal  information  sets  are  required  to 
support  your  functions/decisions? 
o  Do  you  consider  each  of  the  above  mentioned  information 
sets  relevant  and  accurate? 

o  What  factors  are  critical  to  the  success  of  your  function? 
To  understand  concerns 

o  What  if  any,  decisions/functions  are  particularly 
difficult  due  to  a  lack  of  available,  accurate  or 
timely  information? 

o  Would  you  enumerate  any  significant  concerns  or  goals 
you  have  with  regard  to  your  function? 

(a)  What  priority  or  urgency  do  you  attach  to  any  comprehensive 
attempt  to  improve  the  availability,  accuracy  or  timeliness 
of  information  used  by  the  acquisition  community? 

B.  Confirmatory  Portion  of  Interview 

-  Test  each  of  the  hypotheses  and  corollaries  enumerated  for 
completeness  and  correctness. 
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HYPOTHESIS  I 


Information  of  interest  to  the  acquisition  community  is  included 
in  the  following  categories: 

1.  Physical  configuration  data 

2.  Financial  data 

3.  Schedule  data 

4.  Resources  data 

5.  Logistic  Support  Data 

COROLLARIES: 

A.  The  above  data  should  be  cross-categorized  to  include: 

1.  Historical  data 

2 .  Variance  data 

B.  Most  financial,  schedule,  and  resource  data  could  be 
keyed  to  physical  configuration  data. 

C.  Acquisition  managers  at  the  project  manager  level  and 
above  deal  with  most  acquisition  functions  on  a  para¬ 
metric  basis  (cost,  schedule,  technical  performance, 
risk,  principles  of  acquisition  strategy). 

HYPOTHESIS  II 

A  comprehensive  need  exists  for  "acquisition  planning1'  and 
"impact  analysis"  tools. 

COROLLARIES: 

A.  These  tools  require  a  corporate  memory  which  includes 
project  histories. 

B.  This  need  exists  primarily  at  the  project  manager  level 
and  above. 
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EXPANDED  LIST  OF  QUESTIONS 

All  numbered  questions  correspond  to  "revelatory"  questions  shown 
in  enclosure  2.  Lettered  questions  are  specific  examples  or 
follow-up  questions  and  can  be  further  refined  according  to  the 
interview  respondent's  interests. 

To  understand  the  acquisition  environment 

1.  What  environmental  factors  are  critical  to  the  success  of  your 
function? 

(a)  Do  these  factors  derive  from  higher  authority 
(such  as  Congress,  SECDEF) ,  or  are  they  asso¬ 
ciated  with  subordinate  or  contractor  organiza¬ 
tions?  Describe  them. 

(b)  Are  any  of  these  factors  policies  set  by  higher 
authority?  Describe. 


2.  What  significant  information  sets  do  you  generate  for  use  out¬ 
side  your  function? 

(a)  Describe  the  information  you  produce  for  higher 
authority. 

(b)  Describe  the  information  you  produce  for  subordinate 
or  contractor  organizations. 

(c)  Is  this  information  informal  (spoken)  or  formal 
(written)?  If  formal,  is  there  a  policy  or  directive 
stating  a  requirement  for  it? 

(d)  Identify  the  information  by  document  name  (if  any) 
and  logical  content. 
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(e)  Describe  your  perception  of  the  use  this 
information  is  put  to  by  the  recipient. 

(f)  What  is  the  source  of  the  information  you 
produce  for  external  use,  or  how  do  you  develop 
it? 


3 .  What  outside  information  sets  do  you  depend  on  to  perform  your 
function? 

(a)  Describe  the  information  you  receive  from  higher 
authority . 

(b)  Describe  the  information  you  receive  from  sub¬ 
ordinate  or  contractor  organizations. 

(c)  &  (d)  Same  as  2  (c)  &  (d)  . 

(e)  To  what  use  do  you  put  this  information,  i.e., 
what  do  you  do  with  it  or  what  decisions  are 
based  on  it? 

(f)  How  did  the  source  develop  this  information? 

To  understand  functions 


4.  Would  you  categorize  the  decisions  you  make? 

(a)  Describe  the  decisions  you  make,  their  effects, 
and  the  information  you  need  to  make  those 
decisions . 

(b)  Are  these  regularly  recurring  decisions  or  random? 

(c)  Are  these  decisions  made  because  your  organization¬ 
al  charter  requires  it  or  because  you  believe  it  is 
necessary  to  perform  your  function  more  effectively? 
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(d)  Are  these  decisions  well  defined  in  terms  of 
the  state  of  the  needed  information  or  are 
they  based  on  experience  and  an  ill-defined 
set  of  factors? 

5.  What  key  internal  information  sets  are  required  to  support  your 
f unctions/decisions? 

(a)  What  information  do  you  maintain,  privately  within 
your  function  or  organization? 

(b)  What  do  you  do  with  this  information?  Is  it  used 
in  decision  making  or  purely  for  assimilation  into 
externally  sent  information? 

(c)  What  level  of  privacy  or  security  is  appropriate 
for  this  information? 

(d)  Describe  the  information  in  terms  of  its  name 
(if  a  document  or  a  formal  or  informal  file) 
and  its  content  (logical  meaning) .  Is  this  in¬ 
formation  on  paper  or  in  your  head? 

6.  Do  you  consider  each  of  the  above  mentioned  information  sets 
relevant  and  accurate? 

(a)  Do  you  maintain  information  because  you  need  it 
for  your  purposes  or  because  you  are  directed  to 
maintain  it,  or  both? 

(b)  How  much  concern  is  there  about  its  accuracy 
and  timeliness? 

(c)  How  have  you  determined  that  the  information  is 
inadequate? 
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(d)  What  adjustments  do  you  make  when  you  use 
inaccurate/untimely  information? 

7.  What  significant  documents  do  you  generate  or  approve  for 
internal  use? 

(a)  Relate  this  to  question  5 (d) . 

8 .  What  factors  are  critical  to  the  success  of  your  function? 

(a)  Relate  this  to  questions  1(a)  and  (b) . 

(b)  Do  you  have  any  control  over  any  of  these 
factors?  Describe. 

(c)  Are  any  of  these  factors  related  to  facilities 
and  resources  at  your  disposal?  Describe. 

9.  What  decisions/functions  are  particularly  difficult  due  to  a 
lack  of  useful  information? 

(a)  What  effect  does  inadequate/untimely  information 
have  on  your  decision  making?  (Relate  to  6 (d) . 

(b)  If  the  information  were  available  for  your  use, 
would  it  be  developed  by  you  or  within  your 
organization  or  would  it  be  supplied  by  external 
sources?  Describe  the  source  if  external. 

(c)  Describe  the  content  of  the  information  you  need. 

(d)  How  do  you  currently  make  do  without  the  informa¬ 
tion? 
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10.  Would  you  enumerate  any  significant  concerns  or  goals  you  have 
with  regard  to  your  function? 

(a)  Among  those  difficulties  you  expressed,  which  of 
them  is  due  to  the  fact  that  logically  what's  being 
done  is  difficult,  and  which  of  them  is  due  to  in¬ 
adequate  support  mechanisms  (implementations  such 
as  staff  with  calculators  or  computer  tools)? 

(b)  Are  there  any  goals  you  have  regarding  a  better 
way  to  perform  your  function? 

(c)  Are  there  any  goals  you  have  regarding  increasing 
or  decreasing  involvement  with  higher  authority? 

(d)  Are  there  any  goals  you  have  regarding  your 
dealings  with  subordinate  or  contractor  organiza¬ 
tions? 
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INTERVIEW  GUIDELINES 


Gather  Data  on: 

o  Function  and  Responsibilities 
o  Procedures/Processes  in  Use 
o  Decision-Making 
o  Reviewing 
o  Controlling 
o  Planning 
o  Problems/Concerns 
o  Potential  Areas  of  Automation 
o  ADP  Systems  Currently  in  Use 
o  Information  Sources 
o  Information  Uses 
o  Attitude  Toward  Automation 

Interviews  will  be  conducted  with  varying  types  and  levels  of 
people.  Therefore,  questions  will  fit  background  and  qualifi¬ 
cations  of  individuals  concerned. 
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Interview  questions  will  be  modified  to  suit  the  position  and 
qualifications  of  the  interviewee.  Each  interview  will  be 
arranged  ahead  of  time  by  appointment  and  will  normally  be  held 
to  one  hour.  Frequently,  multiple  interview  sessions  will  be 
held  with  the  same  individuals. 

Early  during  each  interview  the  scope  and  purpose  of  the  interview 
will  be  explained  as  fully  as  possible.  Each  interviewee  will  be 
assured  his  responses  will  not  be  identified  with  him  by  name. 

At  the  end,  a  summarization  of  the  main  points  of  the  session  will 
be  made. 
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TYPICAL  INTERVIEW  QUESTIONS  -  FIRST  ROUND 

1.  IDENTIFY  AND  RESEARCH  EXISTING  DOCUMENTS 

1.0  Can  you  identify  any  documents  relevant  to  the 
acquisition  functions  we  are  discussing? 

1.1  Referring  to  certain  documents,  do  you  consider 
them  relevant  and  accurate? 

2.  IDENTIFY  SENIOR  MANAGEMENT  FOR  INTERVIEWS 

2.0  Do  you  wish  to  suggest  other  senior  management 
executives  for  interview? 

3.  ESTABLISH  ACQUISITION  ENVIRONMENT 

3.0  What  documents  do  you  generate? 

3.1  What  factors  are  critical  to  the  success  of  your 
organization? 

4.  DEFINE  BROAD  ACQUISITION  FUNCTIONS 

4.0  What  decisions  do  you  make?--Or  support  as  a 
participant? 

4.1  What  information  is  used  to  support  these  decisions? 

4.2  What  are  the  sources  of  your  information? 

4.3  What  documents  do  you  generate? 

4.4  What  factors  are  critical  to  the  success  of  your 
organization? 

4.5  What  information  is  of  interest  to  you? 

5.  IDENTIFY  CONCERNS  AND  GOALS 

5.0  What  are  your  top  five  concerns? 

5.1  What  were  your  concerns  six  months/year  ago? 

5.2  What  decisions  are  particularly  difficult  for 
lack  of  information? 
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5.3  What  information  do  you  need  that  you  don't  receive? 

5.4  What  information  do  you  receive  that  you  don't  need? 

6.  IDENTIFY  OTHER  PEOPLE  TO  INTERVIEW 

6.0  Do  you  wish  to  suggest  any  subordinate  personnel 
for  interview? 


7 .  FUTURE 

7.0  What  ADP  systems  exist  which  relate  to  your  function? 

7.1  What  areas  do  you  see  as  having  potential  for  automation? 

7.2  What  existing  policies/procedures  could/should  be  changed? 
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Would  you  please  summarize  your  function? 

What  environmental  factors  are  critical  to  the  success  of  your  function 

What  internal  factors  are  critical  to  the  success  of  your  function? 

Could  you  please  review  in  your  mind  the  more  significant  decisions 
you  have  made  during  your  tenure  in  this  position,  and  list  for  us 
the  five  or  so  most  important  ones? 

a)  Can  you  identify  for  us  the  information  you  used  at 
the  time  to  make  those  decisions? 

b)  Can  you  identify  for  us  any  additional  information  you 
didn't  have  at  the  time,  but  wished  you  did  have? 

What  concerns/goals  do  you  have  regarding  your  function? 

It  has  been  suggested  that  having  too  few  people  to  perform  a  function 
can  be  offset  by  improving  via  other  means  the  information  available. 

Do  you  agree  or  disagree? 

Given  the  consensus  that  ship  acquisition  takes  too  long,  what  parts 
of  the  process  can  you  point  to  where  some  of  the  more  significant 
delays  occur? 

a)  Which  of  these  functions  would  be  decreased  in  importance 
during  a  period  of  significant  mobilization? 

Some  feel  that  the  earlier  stages  of  an  acquisition  are  where  the 
more  significant  decisions  are  made  and,  therefore,  that  is  where 
improved  information  will  have  its  greatest  value.  Do  you  agree 
or  disagree? 

Certain  functions  in  the  acquisition  process  have  been  mentioned 
frequently  by  people  we  are  interviewing,  as  areas  potentially 
attractive  to  attempts  to  improve  available  information.  Would 
you  please  give  us  your  opinion  as  to  how  valuable  it  might  be 
in  each  of  these  areas  if  we  were  able  to  provide  better  informa¬ 
tion? 


Attachment  4 


Page  E-44 


FUNCTION  Value  of  Having  Better 

Information  in  This  Area 
Ranking  From  1  (not  of  value ) 
to  5  (very  valuable) 


Acquisition  Planning 

Systematic  Project  Histories 
Change  Management 
Impact  Analysis 

Cost  Estimating 

GFE/GFI  Management 

Project  Financial  Management 

Preparing  Various  Project  Management  Plans 

Project  Problem  Management 

Contract  Administration 

Personnel  Administration 
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F.  Appropriate  Technology  and  Prototype  Recommendations 
—  Authored  by  CCA 


F.l  Introduction 

This  appendix  reviews  high  level  information  require¬ 
ments  of  naval  ship  acquisition  management,  describes 
directly  applicable  technologies,  and  presents  a  prototype 
system  concept.  The  prototype  system  will  enable  the  Navy 
to  experiment  with  the  technology  in  the  near  term,  test 
its  utility  in  the  acquisition  management  environment,  and 
make  informed  decisions  concerning  its  full  scale  imple¬ 
mentation.  The  recommended  system  will: 

a.  provide  access  to  a  large  pool  of  data  relevant  to  all 
aspects  of  acquisition  management; 

b.  present  the  data  in  forms  that  are  far  more  usable 
for  decision  making  —  than  has  been  possible  before; 
and 

c.  provide  tools  that  assist  managers  in  applying  the 
data  to  practical,  everyday  decisions. 

We  believe  that  the  combined  effect  of  these  capabil¬ 
ities,  realized  in  an  integrated  system  design,  will  be  a 
qualitative  change  in  the  practice  of  decision  making  at 
the  strategic  and  policy  levels  of  the  acquisition  commun¬ 
ity. 
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Appendix  F 


This  volume,  Appendix  B,  has  been  prepared  by  Com¬ 
puter  Corporation  of  America  (CCA)  as  a  supplement  to  the 
draft  report  entitled  Automated  SUPPOXL  IPX  Naval  Shi-P 
Acquisition  Management.  (September  5,  1980).  That  main 
report  was  drafted  jointed  by  CCA  and  ROH,  Inc.  This 
volume,  the  main  report,  and  an  Appendix  A  prepared  by  ROH 
will  be  combined  as  soon  as  possible  and  submitted  in 
final  form  as  a  single  document. 


Taken  together,  Appendices  A  and  B  comprise  a 
response  to  a  written  request  from  the  Office  of  Naval 
Research.*  Appendix  B  responds  specifically  to  two  points 
in  the  ONR  request: 


-  "High  level  information  requirements  as  a  reflection 
of  data  retrieval  and  presentation  of  possibilities 
afforded  by  advanced  computer  technologies,  land] 

-  Recommendation  on  prototype  implementation,  and 
experiments  relevant  to  assessing  quality  and 
relevance  of  advanced  MIS  concepts;  e.g.  hardware, 
software,  data." 

(Appendix  A  is  intended  to  respond  to  all  other  points  in 
the  ONR  request.) 


*  Letter  from  M.  Denicoff,  Office  of  Naval  Research,  Oc¬ 
tober  22,  1980,  reference  number  ONR:437 :MD:cds. 
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Appendix  F  Technology  and  Prototype  Recommendations 

F.2  Key  Requirements  and  Applicable  Technology 

Senior  acquisition  management  faces  two  problems  in 
making  effective  acquisition  decisions:  fragmentary  infor¬ 
mation  and  complexity  in  the  inter-relationship  of 
acquisition  factor.  The  technology  to  address  these  prob¬ 
lems  exists  and  has  been  demonstrated  in  government,  mili¬ 
tary,  and  commercial  application. 

This  section  discusses  the  high  level  information 
problems  associated  with  acquisition  planning,  identifies 
some  requirements  for  a  solution,  and  describes  the  graph¬ 
ics,  decision-support,  and  data  management  technology  that 
can  be  applied  to  these  problems  with  near-term  results. 


F.2.1  The  Problem 

In  the  interviews  conducted  in  this  project,  manage¬ 
ment  and  their  staff  acknowledged  that  reams  of  data  are 
available.  However,  no  Navy-wide  scheme  exists  for 
coherent  systematic  collection  of  information  for  senior 
navy  acquisition  managers.  Information  collected  by  vari¬ 
ous  SHAPMs  differs  in  form,  depth,  and  content;  this  is 
also  the  case  for  SUPSHIPs  and  PARMs.  In  addition,  the 
information  is  fragmentary  and  patterns  in  collected  data 
are  not  repeated  often  enough  to  be  recognized.  Because 
of  this,  complex  relationships  among  acquisition  factors 
often  go  undiscovered.  This  latter  problem  is  exacerbated 
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by  the  fact  that  resource  tools  are  not  readily  available 
to  manipulate  the  data  into  forms  in  which  patterns  might 
emerge. 

Another  difficulty  in  senior  decision-making  is  that, 
while  simple  relationships  are  understood  and  can  be 
exploited  in  making  some  projections,  more  complex  rela¬ 
tionships  are  less  well  understood.  Complex,  multi- 
factored  projections  are  therefore  unattainable  or  unreli¬ 
able.  For  example,  the  capability  exists  to  estimate  the 
task  schedules,  given  a  task  dependency  chart  (e.g.,  PERT, 
CPM)  and  a  resource  pool  (e.g.,  shipbuilding  facilities, 
manpower) .  The  capability  to  select  allocation  of 
resources  (e.g.,  several  shipbuilding  facilities,  man¬ 
power)  across  several  projects  (each  having  tasks 
described  by  a  task  dependency  chart)  and  to  minimize  the 
total  schedule  duration  is  more  difficult  to  obtain. 


F.2.2  High  Level  Information  Access  and  Manipulation 
Requirements 

Three  major  requirements  exist  for  solutions  of  these 
problems.  First,  data  from  different  sources  must  be  col¬ 
lected  and  transformed  into  information  by  senior  acquisi¬ 
tion  management.  Second,  tools  must  be  provided  to 
management  that  present  the  information  in  ways  that 
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-  reveal  the  current  state  of  acquisitions,  and 

-  reveal  —  perhaps  through  historic  evidence  the 

(potentially  complex)  relationships  among  various  fac¬ 
tors  that  led  to  the  current  state. 

Third,  tools  must  allow  modeling  of  these  inter¬ 
relationships  for  the  purpose  of  projecting  the  effects  of 
various  acquisition  alternatives. 

The  first  major  requirement  —  collection  of  informa¬ 
tion  for  management  —  can  be  satisfied  with  automation  in 
one  of  three  ways: 

1.  A  new  database  is  created  for  senior  management  within 
SEA90  and/or  MATO 8 .  Its  contents  are  manually  gen¬ 
erated  by  SEA90  or  MATO 8  staff  who  observe  and  record 
pertinent  data.  This  approach  is  costly,  lengthy,  and 
risky,  h  priori  knowledge  of  what  to  collect  is 
required. 

2.  A  new  database  is  created  with  distinct  areas  of  the 
database  private  to  the  various  SHAPMs,  MATO 8 ,  and 
SEA90.  Overlapping  areas  of  the  database  provide  for 
shared  information.  This  is  discussed  in  Section  5  of 
the  main  report.  This  approach  requires  a  lengthy 
startup  to  build  a  significant  amount  of  data. 

3.  Data  currently  available  on  various  SHAPM,  SUBSHIP, 
PARM,  NAVSEA,  and  NAVMAT  databases  through  dialup  or 
network  facilities  is  extracted  (with  permission)  and 
reformatted.  The  reformatted  data  is  stored  in  NAVSEA 
or  NAVMAT  databases  specifically  intended  for  storage 
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of  information  relevant  to  senior  management.  This 
approach  makes  use  of  systems  already  operating  and 
data  already  available;  the  approach  can  yield  results 
within  six  months  to  a  year. 

It  therefore  appears  that,  for  near  term  results,  hetero¬ 
geneous  distributed  data  access  is  required.  (A  fourth 
approach,  a  complete  heterogeneous  distributed  data 
management  system,  is  not  currently  within  the  technol¬ 
ogy.)  Heterogeneous  distributed  data  access  technology  is 
discussed  shortly. 

The  second  requirement,  information  presentation 
tools,  mandates  a  set  of  facilities  for  reorganizing, 
transforming,  tabulating,  displaying,  selecting,  and 
categorizing  data.  These  tools  are  generic,  applying  to 
most  decision-making  environments,  as  would  a  calculator. 
These  capabilities  can  be  provided  by  decision  support 
systems  technology,  particularly  well  when  coupled  with 
graphics  interface  technology. 

The  third  major  requirement  for  modeling  can  also  be 
provided  by  decision  support  systems  technology.  Many  of 
these  capabilities  would  be  oriented  toward  acquisition 
management. 

An  implied  requirement  is  that  these  tools  and  data 
be  directly  available  to  acquisition  managers  and  staff, 
i.e.,  without  a  data  processing  specialist  as  an  intermed¬ 
iary.  This  requirement  can  be  solved  by  an  appropriate 
man/machine  interface,  the  technology  for  which  exists. 


Page  F-7 

Appendix  F 


Technology  and  Prototype  Recommendations 


F.2.3  Technology  Addressing  Those  Requirements 


F.2.3.1  Graphics-Based  Man-Machine  Interfaces 

Recent  advances  in  computer  graphics  technology  have 
made  it  possible  for  a  wide  range  of  users  to  communicate 
effectively  with  computers.  Hardware  technology  now 
includes  higher  resolution  displays,  color,  graphics  capa¬ 
bility  (beyond  simple  character  displays) ,  and  touch- 
sensitive  screens,  all  at  lower  cost.  Software  advances 
now  allow  direct  view  of  the  data  in  a  database  (by  prede¬ 
fined  transformation  of  data  values  to  images)  and  graphic 
manipulation  of  data,  all  without  computer  oriented  com¬ 
mand  languages. 

In  support  of  acquisition  management,  an  automated 
support  tool  could  be  constructed  with  a  graphics  inter¬ 
face.  The  terminal  hardware  could  have  a  touch-sensitive 
color  screen  with  good  resolution,  an  attached  platter  or 
hard  copy  device  for  permanent  copy  of  the  screen,  a  key¬ 
board  for  necessary  textual  communication,  and  a  light 
pen,  tablet,  or  joy  stick  for  more  precise  cursor  posi¬ 
tioning  or  third  dimension  (zoom)  control.  The  software 
supporting  this  terminal  would  provide  acquisition  manager 
staff  (the  end  users)  with  a  means  for  selection  of  com¬ 
mands:  these  means  can  be  live  commands,  one  of  which  is 
selected  by  cursor  position,  or  can  be  labeled  boxes 
presented  on  the  screen  to  be  picked  by  touching.  The 
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command  processor  then  invokes  the  desired  function. 

One  way  to  make  the  system  more  "user-friendly"  is  to 
provide  all  functions  with  a  standard  user  interface.  A 
graphic  interface  could  be  constructed  as  follows:  Once 
involved,  a  function  requests  its  arguments  (parameters) 
by  presenting  labeled  boxes  on  the  screen.  The  user  keys 
in  required  values  and  touches  the  box  the  value  is  asso¬ 
ciated  with.  The  value  moves  into  the  box,  and  this  pro¬ 
cedure  is  repeated  until  all  necessary  parameters  are 
specified.  Parameters  can  be  changed  by  entering  a  value 
and  touching  the  previously  filled-in  box.  Execution 
begins  upon  command.  Upon  completion,  the  function  argu¬ 
ments  can  be  presented  so  the  user  can  modify  parameters 
and  re-execute  the  function.  In  addition,  if  parameters 
can  only  have  a  limited  number  of  values,  these  values  can 
be  presented  for  touch-sensitive  or  cursor  selection. 

The  results  of  executing  a  function  can  be  displayed 
in  a  form  closely  associated  with  the  problem.  Functions 
can  therefore  produce  bar  charts,  histogramy  images, 
tables,  or  text.  Functions  can  be  designed  to  present 
information  in  the  manner  most  revealing  to  the  user. 

Such  interfaces  offer  several  advantages  beyond  that 
just  mentioned.  First,  such  systems  can  be  made  self¬ 
teaching,  in  that  little  instruction  is  needed  to  get 
started  and  no  instruction  is  needed  once  the  user  under¬ 
stands  the  standard  graphic  interface.  Second,  training 
time  is  short  and  minimal  expense  is  incurred  in  training 
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and  refresher  courses.  Third,  the  rate  of  errors  in  com¬ 
municating  between  man  and  machine  is  reduced  because  key 
board  interaction  with  text— based  command  procedures  is 
eliminated  —  where  possible,  correct  choices  can  be 
presented  for  touch  sensitive  or  cursor  selection,  elim¬ 
inating  typographical  errors.  Finally,  these  graphic 
interfaces  are  as  comfortable  for  advanced  users  as  they 
are  for  novices:  they  do  not  suffer  from  the  problem  of 
text  based  command  interfaces  that  are  either  verbose 
(easy  for  novices,  annoying  for  familiar  users)  or  curt 
(fast  for  advanced  user  and  unusable  by  novices). 

Some  examples  illustrate  how  such  a  system  could  sup¬ 
port  senior  Navy  acquisition  managers: 

Display  Form  Example 

line  graph  cost  vs  inflation 


line  graph,  overlayed 


cost  vs  time  for  various 
inflation  rates 


point  plot 


average  cost  or  schedule 
variance  by  contractor 
(Navy-wide) 


bar  graph 


cost  or  schedule  duration 
for  various  acquisition 
strategies 


bar  graph 


schedule  duration  for 
various  contingencies,  e.g.. 


tasks  interrupted  by  funding 
delays,  labor  action,  delayed 


or  changed  GFE,  design  changes. 
These  can  be  based  on  results 
computed  using  decision  support 
tools  described  in  next  section. 


tabular 


preformatted  reports  (e.g.,  NSATS 
SAR) 
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A  wide  range  of  this  technology  has  been  demonstrated  on 
applications  from  SDMS  (Spatial  Data  Management  System),  a 
large  tool,  to  Apple  computer  graphics,  costing  a  few 
thousand  dollars. 


F.2.3.2  Decision  Support  Systems 

A  newly  emerging  class  of  systems,  called  decision 
support  systems,  appears  to  be  applicable  to  acquisition 
management.  Decision  support  systems  are  structured  with 
standard  user  interfaces  (graphic  or  text  based)  to  which 
applicable  functions  for  user  selection  are  added.  They 
generally  start  small,  with  a  core  group  of  generic  func¬ 
tions  like: 

-  plot  (bar  graph,  paint  plot,  line  graph,  histogram) 

-  tabulate 

-  statistics 

-  sort 

-  ntiles  (percentiles,  quartiles) 

that  are  application  independent  and  add  special  functions 
like: 

-  PERT  chart  scheduling 

-  PERT  based  schedule  sensitivity  analysis 

-  resource  reallocation  analysis 

-  cost  vs  inflation  analysis 
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-  cost  estimating 

-  cost/schedule  variance  calculation 

that  are  application  dependent.  These  systems  feature 
simple  data  handling  and  allow  for  growth  in  the  set  of 
allowable  functions. 

Decision  support  systems  are  suitable  for  acquisition 
management  because  they  are  particularly  responsive  to 
differing  or  changing  styles  of  management,  growing  data 
manipulation  needs,  and  growing  needs  based  on  new  experi¬ 
ence  and  learning.  Often,  decision  support  systems  can  be 
implemented  quickly  —  within  a  matter  of  months  for  the 
starting  version  —  and  can  grow  in  a  manner  responsive  to 
need.  New  requirements  are  often  discovered  by  observing 
uses  of  the  functions  available  and  the  information  pro¬ 
duced. 


Some  examples  will  help  show  how  decision  support 
systems  (DSS)  apply  to  acquisition  management: 

Example :  Consider  a  DSS  with  the  following  capabilities: 

-  PERT  or  CPM  type  modeling  (like  PROMAP  or  TRANSIM) 
allowing  task  scheduling  based  on  task  dependencies  and 
resource  allocation 

-  sorting 

-  bar  charting 

This  DSS  has  a  graphic  display  capability. 

In  one  scenario,  an  acquisition  manager  is  interested 
in  determining  the  schedule  duration  for  two  ship  acquisi- 
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tion  projects  given  a  set  of  shipbuilding  resources  to 
allocate.  The  DSS  would  be  used  in  the  following  way: 

Step  1  -  In  gross  detail  develop  the  task  dependency 
chart  for  each  acquisition,  noting  resource 
requirements  for  each  task  with  each  acquisi¬ 
tion.  These  task  dependency  networks  are 
saved. 

Step  2  -  Define  some  ship  building  resource  allocation 
between  the  two  depending  networks. 

Step  3  -  Exercise  (simulate)  the  networks,  yielding  a 
schedule  (with  its  total  duration)  for  each. 

Step  4  -  Repeat  Steps  2  and  3  for  different  resource 
allocations.  The  result  will  be  a  set  of 
data  organized  like 

<  resource  allocation,  duration  of 
project  b> 

<  resource  allocation  #2,  duration 
of  project  a,  duration  of  project 
b> 

Step  5  -  Sort  the  results  of  Step  4  according  to  the 
larger  of  the  durations. 

Step  6  -  Plot  the  bar  chart,  showing  resource  alloca¬ 
tion  on  the  left  (vertical)  axis,  with  dura¬ 
tion  of  both  projects  along  the  bottom  (hor¬ 
izontal)  axis.  The  result,  shown  in  Figure 
2.1,  displays  the  resource  allocation  in  pre¬ 


ferred  order. 
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Figure  F.l 

F.2.3.3  Heterogeneous  Distributed  Database  Technology 

Senior  managers  must  often  make  complex,  multi-factor 
decisions  based  on  inadequate  information.  Ironically, 
much  of  the  information  they  need  exists  in  computerized 
databases  in  the  acquisition  community  or  in  commercially 
offered  databanks.  As  computing  and  storage  costs  con¬ 
tinue  to  decline,  the  wealth  of  available  information  will 
increase  rapidly.  But  with  current  practice,  the  senior 
decision  maker  would  be  no  better  off. 

With  respect  to  computerized  databases,  the  manager's 
problem  is  access.  His  information  needs  are  very  broad: 
the  state  of  the  economy,  the  outlook  in  the  shipbuilding 
industry,  the  pending  budget  actions  in  Congress,  and  the 
status  of  a  large  set  of  diverse,  autonomously  managed 
acquisition  projects  having  operations  dispersed  around 
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the  country.  In  contrast,  the  scope  of  any  individual 
database  is  narrow:  databases  tell  you  a  lot  about  a  par¬ 
ticular  subject.  The  senior  manager  faces  a  dilemma:  he 
cannot  build  the  database  he  needs,  since  this  would 
require  too  much  information  on  too  many  subjects.  He 
typically  cannot  afford  the  time  to  assemble  -  for  any 
given  decision  -  all  the  bits  and  pieces  of  information  he 
might  want  from  the  many  databases  that  contain  informa¬ 
tion  relevant  to  that  decision.  (Even  if  the  manager  had 
the  time  to  wait  for  the  information  to  be  assembled,  he 
would  find  that  no  one  individual  knows  where  it  all  is, 
and  that  the  mechanics  of  assembling  and  combining  it  are 
overwhelming . ) 

Fortunately,  the  technology  to  overcome  this  problem 
has  been  developing  for  several  years  and  is  now  in  the 
first  stages  of  practical  application.  It  is  now  feasible 
to  develop  a  computer  system  that  will  retrieve  informa¬ 
tion  from  many  online  databases  and  will  combine  and 
assemble  the  information  to  answer  a  single  question. 
This  means  that  the  senior  manager  can  employ  an  informa¬ 
tion  strategy  based  primarily  on  exploiting  existing 
information  resources,  rather  than  undertaking  the 
development  and  maintenance  of  massive  separate  databases 
for  the  management  function. 

With  the  new  technology,  it  is  feasible  to  tap  into  a 
set  of  online  databases  that  are:  (a)  heterogeneous,  mean¬ 
ing  that  they  may  be  stored  on  a  variety  of  types  of  com- 
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puters  in  varying  data  structures  and  formats,  and 
accessed  through  diverse  languages;  and  (b)  geographically 
distributed.  This  is  feasible  as  a  result  of  recent  syn¬ 
thesis  of  advances  in  database  languages,  data  models, 
data  translation  techniques,  and  distributed  database 
management.  While  generalized  systems  are  still  in  the 
research  stage,  practical  applications  of  the  technology 
in  specific  areas  are  feasible  now.  For  example,  the 
federal  government  is  currently  using  a  system  to  access 
and  integrate  data  from  6  different  online  systems  -  con¬ 
taining  over  25  databases  on  chemical  substances.*  As  a 
result  of  using  this  technology,  it  is  practical  to  make 
more  informed  decisions. 

The  potential  impact  of  this  technology  on  the 
acquisition  management  process  becomes  obvious  only  in  the 
light  of  available  data.  There  are  hundreds  of  automated 
systems  in  the  acquisition  community.  Many  of  these  con¬ 
tain  online  databases  relevant  to  some  aspect  of  the 
acquisition  management  process.  The  Coordinated  Ship  Data 
System  contains  data  on  ship  production  status  and  plans. 
The  ADCAP  system  contains  data  on  deficiencies  which  may 
affect  ship  cost  and  schedule.  The  Long  Range  Planning 
System  contains  data  on  ship  schedules,  manpower  loadings, 
and  dry  dock  and  berthing  requirements.  There  are  now 

*  See  "An  Intelligent  Terminal  for  Access  to  Heterogeneous 
Chemical  Information  Systems,"  Aren  J.  Horowitx,  Donald  E. 
Eastlake  III,  and  David  Low,  presented  to  the  annual  meet¬ 
ing  of  the  American  Society  for  Information  Sciences,  Oc¬ 
tober  6,  1980. 
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some  600  online  databases  available  from  commercial  ven¬ 
dors.  Data  Resources  Incorporated  offers  macroeconomic 
data  used  in  forecasting  economic  conditions,  interest 
rates,  inflation  rates,  etc.  Disclosure  Incorporated 
offers  data  on  corporations,  based  on  filings  with  the 
SEC.  Dun  and  Bradstreet  offers  services  based  on  the 
largest  proprietary  database  in  the  world.  The  New  York 
Times  Information  Bank  and  the  Wall  Street  Journal  each 
offer  data  -  retrievable  by  individual,  company,  industry 
and  other  subjects  -  on  business  news.  Most  of  these 
database  services  are  aimed  at  serving  large  business 
organizations  and  in  some  way  relate  to  the  needs  of 
senior  decision  makers  in  the  acquisition  community.  The 
online  information  industry  is  expected  to  quadruple  in 
size  over  the  next  5  years,  greatly  increasing  the  infor¬ 
mation  available  to  assist  in  management  decisions. 

By  all  accounts,  a  similar  acceleration  of  the  use  of 
online  databases  within  large  organizations  can  be  antici¬ 
pated.  Thus,  the  amount  of  information  of  potential  value 
to  the  acquisition  manager  in  government  databases  will 
also  increase. 

In  summary,  the  broad  information  requirements  of 
senior  acquisition  managers  are  best  addressed  by  tapping 
into  the  growing  set  of  online  databases  maintained  by  the 
Navy  and  the  information  industry.  This  wealth  of  infor¬ 
mation  can  be  exploited  through  the  application  of 
advanced  database  technology  just  now  coming  into  practi- 
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cal  use.  With  the  new  technology,  a  minicomputer  based 
system  can  retrieve  and  integrate  data  from  diverse,  geo¬ 
graphically  dispersed  databases.  This  strategy  enables 
the  acquisition  community  to  increase  the  value  of  its 
existing  investment  in  online  systems  while  taking  advan¬ 
tage  of  new  systems  and  databases  as  they  develop.  It 
enables  managers  to  begin  to  close  the  information  gap, 
without  themselves  undertaking  commitments  to  maintain  and 
operate  databases. 


F.3  Prototype  System 

One  can  envision  an  acquisition  management  support 
aid  combining  decision  support  system  (DSS)  concepts  with 
graphics  and  heterogeneous  distributed  data  management 
technology.  In  this  section,  we  describe  such  a  system, 
present  an  example  of  its  use,  and  propose  a  scheme  for  a 
prototype  and  incremental  development. 


F.3.1  System  Concept 

The  acquisition  management  decision  support  aid  would 
operate  as  a  small  system  supporting  a  high  resolution 
color  graphics  terminal.  The  terminal  would  have  a  key¬ 
board,  as  a  minimum,  and  potentially  a  color  plate  and  joy 
stick.  The  system  would  have  a  graphics-oriented  inter¬ 
face  for  user  command  processing  and  for  execution  and 
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display  of  results.  The  decision  aid  would  connect  to 
various  databases  and  information  systems  through  network 
and  dialup  facilities.  This  is  shown  in  Figure  3.1. 

Color  Graphic 
Intelligent 
Terminal 


Plotter 


Figure  F.2 


The  support  aid  would  have  at  least  three  classes  of 
functions  available  through  the  terminal: 
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(1)  Generic  functions: 

Display 

-plot  lines  graph 
-plot  bar  chart 
-plot  pie  chart 
-plot  points 

-format  &  display  tables 
-display  matrix 
-others  as  needed 


(2)  Acquisition  management 


Manipulate 

-compute  (arbitrary) 

-calculation  of  formulas 
&  tabulations 

-alphabetize 

-rank... by  (sort) 

-intiles  (percentiles, 
quartiles) 

-average 

-count 

-minimum,  maximum,  others 
as  needed 

specific  functions: 

simulation 


-  task  dependency  network  creation 
scheduling,  resource  allocation) 

-  cost  estimation 

-  task  planning  and  manpower  loading 

-  (CS)  type  project  trading 


(for 


others  as  needed 
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(3)  Data  Management 


nata  Access 


Data  Manipulation 


-browse 


-reformat 


-query  for  data 
with  specific 
condition 


-combine  (JOIN) 


-collect 


-retrieve  (copy) 


-save 


-others  as  needed 


-others  as  needed 


workspace  Manipulation 
-hold  (on  a  temporary  "page") 
-look  at  different  page 
-others  as  needed 


F.3.2  Scenario 

To  appreciate  how  such  a  system  could  operate,  we 
present  an  example  problem  and  use  of  the  system  to  solve 
the  problem. 

A  senior  Navy  acquisition  manager  is  confronted  with 
the  need  to  develop  an  acquisition  strategy  for  a  particu¬ 
lar  project.  Three  shipyards  have  expressed  interest  in 
supporting  this  acquisition,  although  one  has  some  of  its 
facilities  tentatively  allocated  to  another  project.  How¬ 
ever,  the  acquisition  manager  has  the  freedom  to  modify 
that  resource  allocation,  if  the  need  is  sufficient. 
Information  Requirement  1:  The  manager  is  interested  in 
finding  out  as  much  as  possible  about  each  shipyard,  even 
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though  much  information  may  already  be  known. 

Step  1:  The  Acquisition  management  support  aid  is  used  to 
access  the  New  York  Times  Information  Bank  to  find 
articles  about  each  of  those  shipyards  and  its 
parent  company  (if  any).  This  information  is 
saved,  classified  by  company. 

Step  2:  The  Disclosure,  Inc.,  data  service  is  accessed  to 
provide  information  filed  with  the  SEC  by  each  of 
the  shipyards  or  their  parent  companies.  This 
information  and  the  results  of  Step  1  are  col¬ 
lected  and  saved. 

Step  3:  A  procurement  information  system  such  as  NAVSEA 
Active  Contract  Report  and  Completed  Contract 
Report  sponsored  by  NAVSEA  0212  is  accessed  for 
information  on  all  contracts  using  the  shipyards 
of  interest.  This  information  and  the  results  of 
Step  2  are  collected  and  saved. 

Step  4:  Some  sample  of  the  cost  and  schedule  variances  is 
collected  from  the  results  of  Step  3,  for  each  of 
the  three  shipyards.  The  following  calculation 
determines  the  relative  performance  of  the  ship¬ 
yards,  based  on  the  sample  selected.  The  sample 
is  assembled  as  a  set  of  "records"  of  the  form 

<contractor,  contract#,  sched  variance,  total 
schedule,  cost  variances,  total  cost> 

Step  4a:  Compute  variance  percentages,  yielding  Contrac¬ 
tor,  contract#,  schedule  variance  %  (SV%)  cost 


variance  %  (CV% ) > 
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Step  4b:  Compute  a  relative  measure  by  adding  the  %  vari¬ 
ances,  yielding  Ccontractor,  avg  SV% ,  avg  CV% , 
total  var  %>. 

Step  4d:  Rank  by  total  var  %. 

Step  4e:  Produce  a  bar  chart  showing  contractors'  average 
schedule  and  cost  variances.  See  Figure  3.2. 


Figure  F.3 

The  result  of  Steps  1-4,  then,  is  an  assessment  of 
the  three  shipbuilders.  The  second  information  need  is 
for  an  assessment  of  the  impact  of  different  acquisition 
strategies,  e.g.,  one  vs  two  shipyards.  In  this  example, 
assume  that  contractor  C  has  now  been  eliminated  from 
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immediate  consideration  because  of  performance  and  other 
factors  discovered  in  steps  1-3. 

Information  Requirement  2:  The  manager  is  interested  in 
varying  allocation  of  resources  (shipyards)  to  the 
acquisition  to  evaluate  the  effects.  (This  is  performed 
as  described  in  the  earlier  section.) 

Step  5:  Construct  the  major  tasks  and  the  task  dependency 
networks  for  each  ship  of  the  new  project  (New) 
and  the  project  for  which  shipyard  A  tentatively 
has  resources  allocated  (Old) .  Replicate  this 
network  for  each  planned  ship  in  the  new  and  old 
projects. 

Step  6:  Allocate  shipyard  facilities  to  each  such  network; 

exercise  the  network  to  get  a  schedule  duration 
for  old  and  new  projects. 

Step  7:  Repeat  Setup  6,  covering  several  allocations  to 
include  at  least  the  following  strategies: 

a.  Shipyard  A  facilities  ->  old  project 
Shipyard  B  facilities  ->  new  project 
(This  is  a  baseline  for  comparison) . 

b.  Shipyard  A  facilities  partitioned  ->  old 

->  new 

Shipyard  B  facilities  ->  new 

c.  Shipyard  A  facilities  ->  old  (until  complete) 

then  new 

shipyard  B  facilities  ->  new 


The  results  are  collected  in  the  form  Allocation 
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(a,b,or  c) ,  duration  0,  duration  N>. 

Step  8:  Rank  by  maximum  of  duration  for  0  and  N. 

Step  9:  Produce  bar  graph  of  form  shown  in  Figure  3.3. 


Figure  F.4 

The  result  of  steps  5-9,  then,  is  an  assessment  of 
project,  duration  of  both  old  and  new  projects  based  on 
different  resource  allocations.  A  similar  projection 
could  be  developed  for  cost  of  both  projects. 
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F.3.3  Prototype  and  Experiments 

The  incremental  development  of  such  a  system  would 
allow  near  term  support  for  ship  acquisition  mangement  and 
would  incrementally  provide  desirable  features.  We  can 
recommend  a  series  of  implementation  steps  intermingled 
with  experiments  that  assess  the  desirability  of  imple¬ 
menting  various  capabilities  or  access  paths: 

1.  Implement  a  standard  user  interface  applying  the 
graphics  technology. 

2.  Using  dummy  functions  (with  realistic  names),  develop 
a  mockup  of  a  simple  DSS.  Run  an  experiment  with 
selected  users  attempting  to  use  the  system.  The 
experiment  should  assess  the  useability  of  the  inter¬ 
face  for  various  levels  of  pre-use  instruction  and 
various  levels  of  familiarity  (experience  with  the 
interface) . 

3.  Revise  the  standard  interface  as  needed. 

4.  By  averaging  a  number  of  methods  (open  ended  survey, 
questionnaire,  observation) ,  select  some  important 
scenarios  for  decision-making.  Hypothesize  desired 
DSS  functions  and  required  data  access  for  implementa¬ 
tion.  Test  this  hypothesis  by  surveying  the  immediate 
acquisition  management  community.  Access  the  expected 
benefits. 


5.  Implement  the  new  functions  and  provide  for  data 
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access  in  some  form  consistent  with  the  scenarios. 
Observe  use  of  the  DSS,  using  software  to  record  usage 
statistics,  and  compare  actual  use  to  expected  use. 
Measure  actual  benefit  of  use.  Determine  accuracy  of 
benefit  projection.  Determine  whether  use  of  the  sys¬ 
tem  was  consistent  with  the  scenarios  selected  early 
in  Step  4.  Determine  also  what  other  scenarios  the 
system  is  being  applied  to;  i.e.,  identify  unplanned 
uses  of  the  system. 

6.  Based  on  the  new  capabilities  of  the  acquisition 
management  organization  (with  the  support  aid) ,  go 
back  to  Step  4,  hypothesizing  new  functions  and  data 
access  for  implementation. 

7.  Over  a  longer  period  (perhaps  two  cycles  of  steps  4- 
6) ,  measure  the  growth  of  DSS  capabilities,  the 
enthusiasm  for  new  capabilities,  the  actual  use  of  the 
capabilities,  and  the  benefits  perceived. 

This  procedure,  conducted  over  the  life  of  a  proto¬ 
type  project,  effectively  assesses 

1)  application  to  the  acquisition  problem  and  in  its 
application  to  the  user  interface; 

2)  the  Decision  Support  System  approach,  the  growth  and 
utility  of  the  functions; 


3)  the  need  for  specific  and  general  data  access  mechan 
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isms;  and 

4)  the  accuracy  of  benefits  projections. 

Thus,  at  the  end  of  such  a  prototype,  the  Navy  will  have  a 
useable  tool  and  an  understanding  of  the  needs  and  bene¬ 
fits  of  further  development  in  acquisition  management  sup¬ 
port  systems. 


t 
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